fix: avoid lost of events on transmission failure

[gilbertsoft]

Summary

This PR addresses an issue with events get lost when marked for retry e.g. because of a transmission failure. If such events remain after processing, they will be returned back to storage using the ReturnBack method for later handling.

In our case we use a special storage which caches hundreds of events and delivers them once a day or if a number of events in the cache has reached. During our tests we reached the limits and the events which could not be delivered were lost in the end because of the missing handling of this case in the code. It should also be possible to reproduce this problem with the default storage by reaching the limits or cover it by a test which tests the case of a http status 429 returned by the API.

It's maybe a rare case but would be good it could be addressed to avoid the lost of any event.

Checklist

• [X] Does your PR title have the correct title format?
• Does your PR have a breaking change?: No

[rfay]

Ping - We're having to use a fork for this right now. Could you take a look please? Thanks!

[rfay]

Yay, thanks!

[justin-fiedler]

Hey @gilbertsoft just saw that the test coverage is failing. Can you please fix the tests? Otherwise we will take a look next week. Thanks!

[gilbertsoft]

Hey @gilbertsoft just saw that the test coverage is failing. Can you please fix the tests? Otherwise we will take a look next week. Thanks!

Sure, will have a look...

[falconandy]

Hi @gilbertsoft @justin-fiedler I fixed tests.

[gilbertsoft]

Hi @gilbertsoft @justin-fiedler I fixed tests.

Thanks for the update. Just started to debug.

[gilbertsoft]

Hi @gilbertsoft @justin-fiedler I fixed tests.

I left you a comment on the PR, the Return(nil) is not needed here.

[justin-fiedler]

Thanks @gilbertsoft and @falconandy! Fix is released in v1.0.1.