[LeeroyHannigan]

Stacked on #473 (fix/mongodb-update-creates-key): the branch starts at its head, 4e6ccc9, and the PR targets that branch, so MongoDB runs this change with #473's key fix underneath. GitHub retargets it to main when #473 merges.

Summary

UpdateItem on a key that holds no item created a key-only item whenever the update only removed attributes (REMOVE, DELETE, or the legacy AttributeUpdates form with only DELETE actions). Amazon DynamoDB writes nothing for such a request. This change makes all four backends write nothing in that case.

Fixes #478

What changed

• extenddb_core::expression::removes_only(actions) is the shared decision: true when the action list is non-empty and every action is REMOVE or DELETE. An update with no actions at all is not covered, because the service does create a key-only item for it.
• Every backend applies the actions to the key-only image as before, so validation errors are raised exactly as they were, then skips the write, the index maintenance and the stream record when the item was absent and removes_only holds, returning no old and no new image.
  • SQLite (crates/storage-sqlite/src/data/update_item.rs): return before upsert_item_in_tx.
  • PostgreSQL (crates/storage-postgres/src/data/update_item.rs): return before the INSERT ... ON CONFLICT DO NOTHING.
  • Cassandra (crates/storage-cassandra/src/data/update_item.rs): return before the TTL claim and the LWT write.
  • MongoDB (crates/storage-mongodb/src/data_engine.rs): the native fast path runs findAndModify with upsert: false for removal-only updates and answers from the result; the transaction path ends in a new NoWrite outcome that aborts the read-only transaction; the pushdown path returns before replace_one.
• The DataEngine::update_item contract in crates/storage/src/lib.rs documents the exception.
• The engine (crates/engine/src/update_item.rs) is unchanged: with no new image it already omits Attributes for every ReturnValues, charges one write unit, and derives ItemCollectionMetrics from the key, which is what the service returns.

Service measurements

us-east-1, client retries off. Tables: bb-r2-idx (pk S, a GSI on g1pk, no LSI, stream NEW_AND_OLD_IMAGES) and bb-arn-main (pk S, sk S, a GSI gsi1 on g1pk and an LSI lsi1 on l1sk, stream on). Every row below was measured on both tables with the same result, except the rows marked bb-arn-main: ItemCollectionMetrics needs an LSI, which only bb-arn-main has. Fresh key per case; "no item" means GetItem with ConsistentRead returned no Item afterwards.

UTC	request on a missing key	response	item afterwards
2026-10-24 08:45:13	REMOVE a, ReturnValues NONE, ALL_OLD, UPDATED_OLD, ALL_NEW, UPDATED_NEW	200 {} (no Attributes for any of them)	no item
2026-10-24 08:45:13	REMOVE a, b, ReturnValues NONE, ALL_NEW, UPDATED_NEW	200 {}	no item
2026-10-24 08:45:13	REMOVE a.b[0]	200 {}	no item
2026-10-24 08:45:13	DELETE s :v (SS), ReturnValues NONE and ALL_NEW	200 {}	no item
2026-10-24 08:45:13	REMOVE a DELETE s :v, ALL_NEW	200 {}	no item
2026-10-24 08:45:13	REMOVE a with attribute_not_exists(pk), ALL_NEW	200 {}	no item
2026-10-24 08:45:13	REMOVE a with attribute_exists(pk)	ConditionalCheckFailedException	no item
2026-10-24 08:45:13	AttributeUpdates {"a": {"Action": "DELETE"}}, NONE and ALL_NEW	200 {}	no item
2026-10-24 08:45:13	AttributeUpdates two DELETE actions without Value	200 {}	no item
2026-10-24 08:45:13	AttributeUpdates {"s": {"Action": "DELETE", "Value": {"SS": ["x"]}}}, NONE and ALL_NEW	200 {}	no item
2026-10-24 08:45:13	REMOVE a, ReturnConsumedCapacity TOTAL	ConsumedCapacity: {CapacityUnits: 1.0, TableName}	no item
2026-10-24 08:45:13	REMOVE a, ReturnConsumedCapacity INDEXES	{CapacityUnits: 1.0, Table: {CapacityUnits: 1.0}}	no item
2026-10-24 08:45:13	REMOVE a, ReturnItemCollectionMetrics SIZE (bb-arn-main)	ItemCollectionMetrics with the ItemCollectionKey and [0.0, 1.0]	no item
2026-10-24 11:14:27	REMOVE g1pk, l1sk, ALL_NEW (bb-arn-main)	200 {}; queries on gsi1 and lsi1 return nothing for the key	no item
2026-10-24 11:14:27	REMOVE g1pk, ReturnConsumedCapacity INDEXES (bb-arn-main)	{CapacityUnits: 1.0, Table: {CapacityUnits: 1.0}}, no GlobalSecondaryIndexes member; the SET g1pk = :v control charges 2.0 with gsi1 1.0	no item
2026-10-24 12:35:49	REMOVE a ADD n :v, DELETE s :s ADD n :n and ADD n :v REMOVE a, ALL_NEW (bb-arn-main, twice each)	200, Attributes {pk, sk, n: 1}	item {pk, sk, n: 1} created
2026-10-24 08:45:13 to 08:45:34	REMOVE a on a stream-enabled table, LATEST iterators drained for 10 s	0 stream records for that key; the SET control on the same table produced one INSERT record	no item
2026-10-24 08:45:13	controls: SET a = :v; ADD n :v; REMOVE a SET b = :v; AttributeUpdates PUT; AttributeUpdates DELETE plus PUT	200, ALL_NEW returns the created item	item created
2026-10-24 08:45:13	AttributeUpdates {} (no actions)	200 {}	key-only item created
2026-10-24 08:49:02	UpdateItem with no UpdateExpression and no AttributeUpdates	200 {}	key-only item created
2026-10-24 08:45:13	existing item {pk, a, b}: REMOVE a then REMOVE b, ALL_NEW	Attributes {pk, b} then {pk}	key-only item remains

Tests

• tests/test_update_remove_only_missing_item.py (new, dual-target): 64 tests over a hash table, a hash and range table, and a hash and range table with a GSI and an LSI.
  • Removal-only updates on a missing key under every ReturnValues, nested paths, set DELETE, conditions, the legacy DELETE forms and a stream-enabled table.
  • On the index table: no index entry, ItemCollectionMetrics from the key, and ReturnConsumedCapacity INDEXES charging the table only.
  • Two tests write a control item to the table before the removal-only update. On MongoDB, a table that has taken a write and has no GSI serves later updates through the native fast path, and a conditional one through the pushdown path; the earlier tests reach neither. With the removal-only branch disabled in either path, its two tests fail and the rest of the file passes.
  • Controls that still create the item: SET, ADD, REMOVE plus SET, REMOVE plus ADD, DELETE plus ADD, legacy DELETE plus PUT, AttributeUpdates {}, and REMOVE on an existing item.
• At the head, the file passes on SQLite, PostgreSQL, MongoDB and Cassandra (64 of 64 on each). On main with SQLite, 46 fail and 18 pass; the 18 are the controls.
• crates/core/src/expression/ast.rs: unit tests for removes_only.
• crates/storage-sqlite/src/data/update_item_tests.rs: in-memory backend tests for the no-write decision, the SET, ADD, mixed and no-action controls, and REMOVE on an existing item.
• crates/storage-mongodb/src/data_engine_live_tests.rs: fix(mongodb): store the key when UpdateItem creates an item #473's live test of an UpdateItem that creates an item had a REMOVE case that expected a key-only document. That case is now its own live test, live_remove_only_update_on_a_missing_key_writes_nothing: no image, no document, and a PutItem on the key still creates the item. The MongoDB live tests pass 8 of 8 against a replica set.
• Wire tests at the first revision, every test file that exercises UpdateItem (26 files) plus the new file: SQLite 667 passed, 6 skipped, 1 xfailed; PostgreSQL 665 passed, 8 skipped, 1 xfailed; MongoDB with fix(mongodb): store the key when UpdateItem creates an item #473 merged in, 666 passed, 0 failed. The 26-file Cassandra run could not finish on this host: the single Cassandra node stopped answering partway through, while the new file had passed.
• crates/storage-mongodb/src/data_engine.rs (4,475 lines) and crates/storage/src/lib.rs (1,028 lines) were over 600 lines before this change, which adds 44 and 4 lines to them; they are not split here.

Interactions with open PRs

• fix(mongodb): store the key when UpdateItem creates an item #473 (fix/mongodb-update-creates-key): this PR's base. fix(mongodb): store the key when UpdateItem creates an item #473 makes the MongoDB native upsert store the key when UpdateItem creates an item, and repairs stored documents that have no item data into key-only items. This change removes one source of such documents: before it, a REMOVE-only UpdateItem on a missing key created a document with no item data on MongoDB (the 500 in MongoDB: UpdateItem that creates an item stores it without its key attribute, and every later PutItem on that key answers 500 #436). Documents created that way before both changes land are what fix(mongodb): store the key when UpdateItem creates an item #473's repair turns into key-only items; after this change no new ones are created by REMOVE or DELETE, and the repair stays correct for the ones that exist. The native fast path keeps fix(mongodb): store the key when UpdateItem creates an item #473's $setOnInsert for SET and ADD and uses upsert: false for removal-only updates. On main alone, MongoDB answers the mixed controls (REMOVE a SET b = :v, legacy DELETE plus PUT) without the key attributes, which is MongoDB: UpdateItem that creates an item stores it without its key attribute, and every later PutItem on that key answers 500 #436 and the reason this PR sits on fix(mongodb): store the key when UpdateItem creates an item #473.
• fix(storage-cassandra, #310): return proper 400 when a secondary index key is set to an empty value #417 (fix/issue-410-update-item-500) and fix(postgres): build a GSI added by UpdateTable correctly while writes continue #401 (fix/pg-online-gsi-backfill): both insert a secondary-index key check after the item-size validation in the Cassandra and PostgreSQL update_item.rs, where this change inserts its early return; git reports an adjacent-insertion conflict. Resolution: keep both, their check first, then the early return. The order does not change any answer: for a removal-only update on a missing key the new image is the key alone, so the index-key checks have nothing to refuse.
• fix(expressions): validate in the service's order, with its messages #399 (fix/transact-validation-order): both edit the pub use lines in crates/core/src/expression/mod.rs. Resolution: keep both exports (removes_only from ast, compare_orderable from evaluator).
• Clean merges: fix(mongodb): retry an unconditional PutItem that conflicts on a GSI table #487, fix(mongodb): retry a write conflict on the stream sequence counter #475, feat(streams): AT_TIMESTAMP shard iterator on all four backends #468, fix(streams): one clock read per stream record on all four backends #463, fix(mongodb): retry an unconditional PutItem that loses the create race #431, fix(query): classify and order key conditions on a multi-attribute GSI the way the service does #429, fix(limits): size items and updates the way the service does #409, Store U+0000 in strings on PostgreSQL and MongoDB #368. Branches that already conflict with main on files this change does not touch: fix(storage-cassandra): index rows follow the base item under every write path #424, fix: validate secondary-index keys on UpdateItem and transaction writes the way the service does #416, feat(storage): SnapshotEngine, a consistent table snapshot on every backend [backup/restore 4/4] #395, End GetRecords iterators after closed shard exhaustion #372, fix(backup): report point-in-time recovery as unsupported #335, Add TiDB storage backend #140, fix: Use consistent snapshot for ExportTableToPointInTime #80.

Not changed here

• TransactWriteItems with an Update whose actions are all REMOVE or DELETE on a missing key still creates a key-only item on every backend. The service writes nothing for it (measured 2026-10-24 08:49:02 UTC, REMOVE a, REMOVE a, b, DELETE s :v, and REMOVE a with attribute_not_exists(pk), both tables, ConsumedCapacity 2.0 write units like the SET control). The transaction update path is separate code in each backend, so it is a separate change. No issue is filed for it yet.
• REMOVE a SET a = :v on the service is rejected with "Two document paths overlap with each other; must remove or rewrite one of these paths; path one: [a], path two: [a]" (measured 2026-10-24 08:49:02 UTC). Not checked against ExtendDB here.