Spit log message whenever we retry processing an event

[mjward]

Context

The default behaviour when an error occurs for EventProcessors in EventSourcery is to kill the process and immediately respawn and try again.

@jiexinhuang created the ExponentialBackoffRetry error handler for RSS, which wouldn't kill the process, it would as the class name indicates, exponentially back off retrying processing the failed event until successful.

The issue we have with this is there is not a lot of transparency as to how often this is occurring, and/or how long it takes to be successful upon retry.

Change

An additional line in the logs should highlight how often retries are occurring together with how long it takes for that retry to be successful.

Considerations

This only impacts you if you are using the ExponentialBackoffRetry error handler (which I think might only be RSS? not 100% on that)

Paired with @charithperera

[amanda08]

:+1: This would be super useful. We're using ExponentialBackoffRetry in Shoebox as well.

[mjward]

@twe4ked just looked at the CHANGELOG and it looks like you have had stuff there pending a release. Seeing as this project is now open source, removing functionality/methods which is potentially a breaking change feels like a major release? Would you agree? https://semver.org/

[twe4ked]

Yeah that's what made me think about it. I think a 0.16.0 is probably a good idea. We'll need to release the -postgres gem too because it relies on one of the removed methods IIRC. Sorry.

[mjward]

According to https://semver.org which I like to adhere to anything that breaks the API in an backwards-compatible manner would be a major release. Hence we are looking at 1.0

Removing core methods that drive event processors feels like a heavy change to me (even if we haven't personally used them at Envato for awhile). Open sourcing this repo requires us to be predictable and consistent with versioning otherwise we run the risk of breaking other peoples projects that may be now relying on this gem.

[orien]

Before version 1.0 is released, any change is allowed. I don't think we should release a version 1.0 until we ready to commit to the API.

https://semver.org/#spec-item-4

4. Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

[joesustaric]

@mjward and @twe4ked I had a similar brief discussion RE: versioning for the msql version of this gem (yet to be open sauced).. < v 1 is predictable .. that is it should be treated as a rapidly changing unstable API to anyone using it. bumping the minor version when its < v1 users should not be surprised that there might be something breaking..

I think we should have been on v1 already with this gem tbh.. feels like it's been 'stable' for a while now... +1 for bumping it to v1.0 feels like its ready regardless. :)

[joesustaric]

haha @orien we posted almost at the same time.. But yeah I see your point.. we should agree on the 'stable' API then v1 it. 👍

[mjward]

okie dokes, happy to keep it at 0.16 just want to make sure we are all on the same page. I do think its probably overdue for a review of a bump to 1.0 though as @joesustaric mentions. It can't stay in development forever.

[orien]

To be clear I'm not against releasing a 1.0 now. Rather that it should be a conscious choice to do so.

And to clarify, Semantic Versioning isn't forcing us to do so with this change.

[joesustaric]

Look to the semantic versioning for guidance 🔮

How do I know when to release 1.0.0? If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.