We are aware that it is very difficult to achieve a perfect stability of your sink. Sometimes your infrastructure may have problems and you won't be able to receive the events. EventStreams is ready for that and incorporates several mechanisms to cope with these issues.
EventStreams will retry delivering an event for at most four hours.
EventStreams will notify you about any issue listed here using Twilio Debugger. Depending on your configuration you will receive mailing events, lists in Twilio Console or both. You will receive a notification after the first error and then more grouped at certain points: every 20 minutes, every 10/100/1000.. error and so.
Under certain conditions (see tables below) the delivery of an event will be retried several times. This retry is performed with an exponential backoff with jitter, meaning that each retry is increasingly separated from the next. The delay between retries includes some randomness. Retries continue in this manner (if the retries continue to be unsuccessful) for four hours.
Note that the target of 2 seconds delivery only applies for the first delivery attempt of an Event, not for Events with retried deliveries. There is a significant chance of Events being delivered out of order in the case of retries, so you should use each Event's timestamp to sort Events if needed.
Issue | Error code | EventStreams behavior |
---|---|---|
Error writing to Kinesis | 93101 | Retry delivery |
assume role error | 93102 | Retry delivery |
get shard count error | 93103 | Retry delivery |
get Kinesis Stream Name And Region error | 93104 | discard event |
Issue | Error code | EventStreams behavior |
---|---|---|
customer returning 429 HTTP error | 93101 | retry delivery |
customer returning other 400 HTTP error (not 429) | 93101 | discard event |
customer returning any 500 HTTP error | 93101 | retry delivery |
Currently this sink does not notify the customer in case of issues