Does DESelect Segment have a retry policy?

yes, deselect segment implements a retry logic for all selection runs, normal and scheduled what is a retry logic? a retry logic is a method used to deal with unsuccessful operations it is only useful for transient failures and it helps improve the stability of an application the concept behind a retry logic is that on an operation failing, the system automatically retries to perform the exact same operation, until it succeeds, or for a set number of times when is the retry triggered? the retry logic gets triggered by specific messages and does not always start by itself the sfmc messages that trigger the retry are the following error saving additionalquerypart this error occurs sometimes on sfmc server when it is too busy to process a request that includes a lot of filters the recommended workaround from sfmc support is to retry the request a network related or instance specific error occurred while establishing a connection to sql server the server was not found or was not accessible this error can occur when sfmc failed to connect to its database, and therefore cannot serve our request connection timeout expired the timeout period elapsed while attempting to consume the pre login handshake acknowledgment this could be because the pre login handshake failed or the server was unable to respond back in time our connection to sfmc took too long to complete and timed out how does the retry logic work? whenever deselect receives one of the retry messages as the response from sfmc the retry gets triggered the maximum amount of times deselect will retry this is 3 times the retry will be terminated earlier only if we get a response that the operation was completed successfully we get a response that the operation failed with a message that is not a retry message between the attempts, there is an incremental wait time of 1 second the first retry will happen 1 second after the original run failed if it fails, the next one will wait 2 seconds before running the final retry attempt will run 3 seconds after the second one failed how can you tell if a specific run was retried? whenever a selection is retried, but still fails to complete, a custom message is shown to the user looks like sfmc server is currently too busy to process your request please try again in a few minutes for more information, create a support case here this message will show up in all these places the status column of the selection the selection run logs if the selection is scheduled it will be included inside the body of the email the user received apart from this message, there will be no indication to the user that the retry occurred in cases where the retry was triggered, and the selection completed successfully, the user will not be made aware that the retry occurred can the retry logic be extended? we want to make sure we provide the best experience for our users therefore, we are looking into extending the messages that trigger the retry feel free to reach out to us here with any ideas regarding sfmc messages that could be added to the policy