Distributed event bus retry strategy

[GreatGodJackChen]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Abnormal consumption of the message bus can lead to infinite loop consumption, and no solution has been seen so far. Can we only write our own retry strategy? This is a commonly used feature, and based on the principle of out of the box use, it should be built into the framework, otherwise it will appear like a semi-finished product. In the generation environment, this practice should be avoided, as it can lead to catastrophic accidents if not handled properly*******

Describe the solution you'd like

Refer to the masstransit retry strategy

Additional context

The current design is completely unable to be directly applied to production

[realLiangshiwei]

See #23563

[GreatGodJackChen]

See #23563

After a retry fails, should Inboxes messages be retained or deleted? Messages that have been successfully consumed can be deleted within the configured time, but those that have failed to be consumed should be retained for a long time and wait for exception handling

[maliming]

You can configure the InboxProcessorFailurePolicy

• InboxProcessorFailurePolicy: The policy to handle the failure of the inbox processor. Default value is Retry. Possible values are:
  • Retry: The current exception and subsequent events will continue to be processed in order in the next cycle.
  • RetryLater: Skip the event that caused the exception and continue with the following events. The failed event will be retried after a delay that doubles with each retry, starting from the configured InboxProcessorRetryBackoffFactor (e.g., 10, 20, 40, 80 seconds). The default maximum retry count is 10 (configurable). Discard the event if it still fails after reaching the maximum retry count.
  • Discard: The event that caused the exception will be discarded and will not be retried.
• InboxProcessorRetryBackoffFactor: The initial retry delay factor (double) used when InboxProcessorFailurePolicy is RetryLater. The retry delay is calculated as: delay = InboxProcessorRetryBackoffFactor × 2^retryCount. Default value is 10.

[GreatGodJackChen]

InboxProcessorFailurePolicy if I want to use Retry mode to not perform after error number, need to step in dealing with before execution, discarding the event rather than RetryLater mode;

Can these three modes target events rather than the entire service

[maliming]

It does not support your case. You can override InboxProcessor to customize it.