[LeeroyHannigan]

On MongoDB, an UpdateItem or DeleteItem condition with about 100 nested AND or OR terms answered InternalServerError. It is now evaluated, and the request answers as DynamoDB does.

This branch is stacked on #558, because it removes the expected-failure marker #558 put on its 150-term UpdateItem condition row for MongoDB.

What happened

On a table with no index and no stream, the MongoDB backend has a fast path for conditional writes. It compiles the condition into a MongoDB filter and sends it with the key filter, through find_one for UpdateItem and find_one_and_delete for DeleteItem. The compiler emits one $and, $or or $nor level per operator, and a chain such as #v = :v OR #v = :v OR ... parses left-nested, so 150 terms become 149 nested levels. MongoDB refuses a command nested past its BSON depth limit with error 15 ("BSONObj exceeds maximum nested object depth"), and the server answered InternalServerError.

The fast path runs only while the server's per-process cache holds an entry recording that the table has no index. A write on the session path creates that entry, and it lasts 60 seconds. Outside that window the same request took the session path and answered correctly.

Measured on mongo:7.0.45 through those two calls, with the key filter merged in, a condition nested 98 levels runs and 99 fails. With contains leaves, the deepest leaf the compiler emits, 97 runs and 98 fails. Right-nested and alternating chains have the same limits, and list index paths add no nesting.

What the service answers

Measured in us-east-1 on 2026-10-25 between 18:34 and 19:55 UTC, each failing case sent twice with the same answer:

• On an absent key, these conditions answer ConditionalCheckFailedException: a 150-term OR chain, a 150-term AND chain, OR and AND alternating 100 and 140 levels deep, a 120-term OR inside an AND, and a legacy Expected map of 120 entries joined by ConditionalOperator OR. The same holds with 300 and 301 Expected entries.
• When such a condition holds, UpdateItem and DeleteItem apply the write, including ReturnValues ALL_OLD, ALL_NEW and UPDATED_NEW, and a TransactWriteItems ConditionCheck.

The change

is_pushable now refuses a condition whose AND, OR and NOT nest more than 64 levels deep. Such a condition takes the session path, which evaluates it in Rust, as it already does for every condition the analyzer does not accept. At 64, the deepest filter a pushable condition produces is 134 levels against MongoDB's 200. A condition loses the fast path only with 65 or more AND, OR and NOT operators along one path, and the answer is the same on either path.

The first commit moves the analyzer's unit tests from pushdown.rs (635 lines) to pushdown_tests.rs, unchanged, loaded with #[path] as backup_engine.rs loads its test files. The module documentation and section 5.2 of docs/design/13-storage-mongodb.md list the new condition that is not pushed down.

Tests

• Unit: logical_nesting_past_the_limit_is_not_pushable checks the boundary at 64 and 65, a 150-term chain, a depth of 97 refused whatever the limit, and that NOT and both sides of an operator count. Four altered versions of the change each fail it: the check removed, the limit raised to 100, NOT not counted, and only the left side counted.
• Wire: tests/test_condition_nesting_depth.py, 17 dual-target tests built from the measured rows above, on UpdateItem and DeleteItem with conditions that fail and conditions that hold, and the legacy Expected rows. Each test creates its own table and writes to it first, so on MongoDB the conditional write runs while the cache entry that enables the fast path is fresh.
• tests/test_expression_operator_limits.py: the expected-failure marker on test_update_item_condition_at_the_cap_is_evaluated is removed.

Run locally on 2026-10-25 against release builds, MongoDB on mongo:7:

• the new file on MongoDB: 17 failed before the fix, every one with InternalServerError and error 15 in the server log; 17 passed after it, with no error 15;
• the new file and test_expression_operator_limits.py after the fix: 95 passed on MongoDB, 95 passed on SQLite; an earlier version of the new file, with 11 of the 17 rows and one table for the whole module, passed on PostgreSQL;
• test_expression_operator_limits.py before the fix on MongoDB: the unmarked cap row fails with InternalServerError and the other 77 pass;
• cargo +1.97.0 fmt --all -- --check, cargo +1.97.0 clippy -p extenddb-storage-mongodb --all-targets -- -D warnings, cargo test -p extenddb-storage-mongodb --lib (123 passed), and the pushdown unit tests on 1.88.0.

CI collects the new file in mongodb-pytest, run-integration and run-integration-sqlite.

Merging

git merge-tree --write-tree against the 13 open PRs that touch the MongoDB analyzer, compiler or data engine is clean for 10. #429 conflicts with #558 in key_condition.rs, and #416 conflicts with main; neither conflict involves this branch's files. #368 adds two tests inside the test module that the first commit moves. To resolve it, keep #[path = "pushdown_tests.rs"] mod tests; and move #368's nul_attribute_name_is_not_pushable and control_character_attribute_alias_is_not_pushable into pushdown_tests.rs, one indent level out. The pushdown unit tests pass 24 of 24 on the merged tree.

Found while testing, not changed here

These are on main, filed separately:

• On MongoDB, an UpdateItem that SETs a string starting with $ together with a numeric ADD (SET #s = :s ADD #n :one, :s is {"S": "$item_data"}) answers InternalServerError, and a later GetItem of that key also answers InternalServerError. The service stores the string (MongoDB: SET of a $-prefixed string with a numeric ADD answers 500 and corrupts the item #573).
• On MongoDB, a condition on a nested map member that the fast path accepts (attribute_exists(#m.#k) AND #m.#k = :v) answers ConditionalCheckFailedException when it holds. The service applies the write (MongoDB: a condition on a nested map member fails when it holds #572).
• On every backend, an UpdateItem whose result nests more than 32 levels is applied. The service refuses it with Nesting Levels have exceeded supported limits (UpdateItem: a result nested more than 32 levels is applied; the service refuses it #574).