MongoDB: concurrent UpdateItem calls that take the session path answer TransactionConflictException (RFC-0003 4.4) #809

Summary

RFC-0003 4.4 requires concurrent UpdateItem calls on one item to succeed and to apply cumulatively. On MongoDB, an update that the native pipeline does not take runs in a session transaction with optimistic retries. With 50 concurrent clients, some of those calls run out of retries and answer TransactionConflictException.

Measured on MongoDB 7 against a debug build of #803 (5803642): 50 threads each sent 20 UpdateItem calls to one item, with SDK retries off.

No committed update was lost: each result matches the calls that succeeded.

Cause

try_build_native_update in crates/storage-mongodb/src/data_engine.rs builds a native update only for SET of a value, REMOVE, and a number ADD within the native digit limits that #803 adds. Every other update, SET with arithmetic among them, takes the session path. That path retries a write conflict TRANSIENT_RETRY_ATTEMPTS (50) times, with a jittered backoff of at most 12.8 ms, and then answers TransactionConflictException.

SET with arithmetic never had a native path, so main has the same gap. A number ADD outside the digit limits took the native pipeline on main, where the sum could round or leave DynamoDB's range.

Fix shape

Either serve more updates natively, for example SET a = a + :v as an $add pipeline with the same guard as ADD, or change how the session path handles a conflict on one item. The 4.4 test in tests/python/test_rfc0003_concurrency.py covers only ADD of 1. A dual-target case for SET with arithmetic would catch this.

Not measured: a counter whose sum the native pipeline writes with an exponent, such as 1E-7. The next ADD to it takes the session path.