Problem
On the Cosmos document tier, a participant command that a received handler dispatches in-process (for example with context.InMemory()) loses its writes with no error.
DocumentTierBatchLifecycleBehavior<TMessage>.Handle (src/Chatter.MessageBrokers.Reliability.Cosmos/src/Chatter.MessageBrokers.Reliability.Cosmos/Reliability/DocumentTierBatchLifecycleBehavior.cs, around lines 66-108) gates on the participant registry plus a non-null inbound message. A nested participant command dispatched with the outer IMessageBrokerContext sees the same inbound message, so it opens a second TransactionalBatch and stages a Co-Resident Inbox Marker at the same deterministic id. When that batch executes, the marker write returns 409, which this tier treats as a confirmed duplicate and acknowledges. The nested handler's aggregate writes are discarded.
Root cause
The same class as #534: the delivery's identity is inherited by nested in-process dispatch, so a nested command is treated as if it were the delivery itself.
Bounded impact
Silent data loss, limited to consumers on the Cosmos document tier who both register a nested command as a participant and dispatch it in-process from a received handler. Not introduced by the #534 fix.
Why it is not fixed with #534
The #534 fix changes InboxBehavior so only the message a delivery admitted is inbox-gated. The document tier has its own gate. The right remedy here is different: the nested participant should join the outer framework-owned batch through the existing Atomic-Write Handle rather than open a second batch. That is a design task under ADR-0008's participation model, in a different package (Chatter.MessageBrokers.Reliability.Cosmos).
Related
#534, ADR-0008, ADR-0009, ADR-0041 (added by the #534 fix).
Problem
On the Cosmos document tier, a participant command that a received handler dispatches in-process (for example with
context.InMemory()) loses its writes with no error.DocumentTierBatchLifecycleBehavior<TMessage>.Handle(src/Chatter.MessageBrokers.Reliability.Cosmos/src/Chatter.MessageBrokers.Reliability.Cosmos/Reliability/DocumentTierBatchLifecycleBehavior.cs, around lines 66-108) gates on the participant registry plus a non-null inbound message. A nested participant command dispatched with the outerIMessageBrokerContextsees the same inbound message, so it opens a secondTransactionalBatchand stages a Co-Resident Inbox Marker at the same deterministic id. When that batch executes, the marker write returns 409, which this tier treats as a confirmed duplicate and acknowledges. The nested handler's aggregate writes are discarded.Root cause
The same class as #534: the delivery's identity is inherited by nested in-process dispatch, so a nested command is treated as if it were the delivery itself.
Bounded impact
Silent data loss, limited to consumers on the Cosmos document tier who both register a nested command as a participant and dispatch it in-process from a received handler. Not introduced by the #534 fix.
Why it is not fixed with #534
The #534 fix changes
InboxBehaviorso only the message a delivery admitted is inbox-gated. The document tier has its own gate. The right remedy here is different: the nested participant should join the outer framework-owned batch through the existing Atomic-Write Handle rather than open a second batch. That is a design task under ADR-0008's participation model, in a different package (Chatter.MessageBrokers.Reliability.Cosmos).Related
#534, ADR-0008, ADR-0009, ADR-0041 (added by the #534 fix).