BrighterCommand / BrighterCommand/Brighter

[Feature] Inbox Support for "Crash Only" or "Replay"

Open
#2,540 1 comment 0 reactions 1 assignee Claimed by @iancooper View on GitHub
2 - In Progress feature request V10.X
Dominant language
C#
Stars
2.5k
Forks
296
Avg merge
1d 11h
Merged PRs (30d)
21

Description

Fundamentally with an inbox we store two things: I have received this; I have processed this.

- I have received this => mainly useful for tracking how we got to current state i.e. what have we seen.
- I have processed this => mainly useful for tracking that we should not apply this again because the operation would not be idempotent.
-

We use the former to recover from outages, the latter is used for coping with "at least once."

Now you do normally choose only to ack once you have processed, so leaving a message in the queue means that you will reprocess it, and typically we let you reprocess unless you have flagged "I have processed this".

But issues do happen. Typically it is "there was a bug, and so I processed it and acked it, but my bug means I did not complete the required actions and now the downstream is incorrect". An option here is to then reprocess from your inbox. Of course to do that, I have to have a model of reading my inbox and reprocessing anything that is not "processed" at start up (this helps with crash only software as well btw) so that I can just wipe out the processed dates of various messages to force them to be replayed through the pipeline.

Now, today, we don't do that out of the box but I have always thought it would be useful to support an option to re-process incomplete inbox commands at startup.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.