Adds a settings-only option to use Outbox in SendsAtomicWithReceive mode #7497
Conversation
Remove whitespace Tweaks Use simple namespace Fix inspections Try FIFO mode for the AT transport to ensure strict message processing order Fix whitespace Add ControlMessage header Use context.Extensions in SetAsDispatchedBehavior Split OutboxSeam into two dedicated classes Minimal version Remove test changes
|
How would a downstream implement this? Are you saying you plan to add some features to a downstream that then modifies the pipeline execution? |
|
I have been thinking about this a bit more today, and I believe that before adopting an approach like this, we need to consider whether it provides any real-world value. As far as I understand, one of the main IO costs in the outbox implementation is storing the transport operations. We would still need to do that. The only real gain would be the ability to delete the deduplication entry, but that also implies that no one should ever send the same message with the same ID again. We might currently rely on the presence of a deduplication entry for a certain period to support ideas around transactional sessions by using a stable ID for business operations. That capability would be lost if the dedup entry is removed too early. Additionally, while this would reduce storage requirements by no longer persisting a GUID, it introduces an extra control message. For each outgoing message, this means that on a standard Azure Service Bus tier, we would be charged two operations instead of one, adding another tradeoff. I think it would be useful to compare these tradeoffs to determine whether the change actually provides a tangible advantage. |
SendsAtomicWithReceivetransaction mode (enabled via a settings value)TransportReceiveToBlaBlaConnectorand theIOutbosStorageby introducingIOutboxSeam. This change is needed to implement outbox scenarios that diverge from the default one.