Addition of retry-count in the event headers to identify the retry count of an event
Summary
Addition of retry-count in the event headers to identify the retry count of an event
Use Cases
It will be helpful to see how many times an event is being retried , hence addition of a new field in the datum can help When would you use this?
Message from the maintainers:
If you wish to see this enhancement implemented please add a 👍 reaction to this issue! We often sort issues this way to know what to prioritize.
This can only be an approximate and need not be monotonically increasing. If the pod crashes in between, the counter will be reset.
This can only be an approximate and need not be monotonically increasing. If the pod crashes in between, the counter will be reset.
Yes, will be same as our retry strategy.
could this include some level of retry configurability? I am thinking something like adding backoff timers, reset watermark for event in case of "retryable error", retry from vertex vs retry from source.