plan/spec: the operator corpus goes green

102/102. PLAN's M3 row now names both corpora as the gate, because neither the
pinned crud suite nor e2e3/e2e4 can see this work: the eight operators are
barely in the pinned corpus and `$push`'s modifiers are not in it at all.

§6 records what the corpus found that was nobody's operator -- an upsert never
reporting the `_id` it generated -- and the three things left open on purpose:
`$bit`, a multi-field `$sort` key inside `$push`, and the 64-path bound on the
conflict check.

Full matrix at this commit: 247/247 unit tests in ReleaseFast and ReleaseSafe,
83/83 fuzz, operators 102/0, positional 51/0, aggregation 70/0, pinned crud
218/73/196 unmoved, e2e and crash-fuzz green.
This commit was merged in pull request #8.
This commit is contained in:
A.Shakhmatov
2026-08-10 21:33:45 +03:00
parent 71e3879ae0
commit 44788ae681
2 changed files with 40 additions and 12 deletions

View File

@@ -58,21 +58,27 @@ as a bare number would not have said so.
## Where it stands
Recorded against mongod 8.3.7, run against the server before any of it was
implemented:
Recorded against mongod 8.3.7. Green:
```
array-ops.json 2 pass 24 fail 0 skip
current-date.json 3 pass 8 fail 0 skip
modifiers.json 7 pass 7 fail 0 skip
numeric.json 0 pass 21 fail 0 skip
push-modifiers.json 6 pass 15 fail 0 skip
set-on-insert.json 0 pass 9 fail 0 skip
array-ops.json 26 pass 0 fail 0 skip
current-date.json 11 pass 0 fail 0 skip
modifiers.json 14 pass 0 fail 0 skip
numeric.json 21 pass 0 fail 0 skip
push-modifiers.json 21 pass 0 fail 0 skip
set-on-insert.json 9 pass 0 fail 0 skip
```
Red by construction. The 18 that pass are the shapes this server already
answers the way mongod does — mostly refusals that happen to agree, plus the
`$push` cases with no modifier on them.
It was recorded red — 18 pass / 84 fail against a server with none of these
operators — and driven green by seven commits. The 18 that passed then were
the shapes this server already answered mongod's way, mostly refusals that
happened to agree.
It also found a bug nothing else here had: an upsert never reported the `_id`
it generated, so `updateOne(..., {upsert: true}).upsertedId` was null and
`findOneAndUpdate` with `returnDocument: after` returned a document with no
`_id`. This is the first corpus here that upserts into an empty collection and
then looks at what came back.
## What recording it settled