[jeremydmiller]

Closes #5743, found today while implementing #5740's undelete.

Root cause

When ApplyCallbacksAsync post-processes a batch, it calls NextResult after every operation that is not a NoDataReturnedCall.

• UndoDeleteWhere and HardDeleteWhere queue a bare StatementOperation. So does the projection UnDelete path.
• StatementOperation was not marked NoDataReturnedCall, although its subclasses Deletion (through IDeletion) and PatchOperation always were.
• Its UPDATE or DELETE produces no result set, so that NextResult skipped the next operation's result instead.
• A numeric-revision upsert queued after it then read nothing back and threw ConcurrencyException for a write that had not conflicted. It did so even when the statement matched nothing.

DeleteWhere was never affected because it builds a Deletion. That is why the issue's table shows it working.

Fix

StatementOperation : Statement, IStorageOperation, NoDataReturnedCall, with a remark saying why the marker is load-bearing.

The projection UnDelete paths had the same misalignment. It was harmless there only because the upsert after them ignores revision conflicts (IgnoreConcurrencyViolation, or Revision == 0).

Tests

DocumentDbTests.Deleting.Bug_5743_statement_before_revisioned_upsert:

• UndoDeleteWhere, then UpdateRevision(note, 2): red on master (ConcurrencyException), green here.
• HardDeleteWhere, then UpdateRevision(note, 2): red on master, green here.
• A genuinely stale UpdateRevision(note, 1) after the statement is still refused, so the fix does not switch the guard off.

Regression runs (net10.0, PG 17):

• the whole DocumentDbTests.Deleting namespace: 83 passed, 1 skipped;
• the EventSourcingTests soft-delete, ShouldDelete and archiving projection classes: 49 passed, 1 skipped.

#5744's UndeleteDocumentAsync queues the upsert before UndoDeleteWhere to step around this bug, and its comment says so. That ordering stays correct after this fix.

🤖 Generated with Claude Code