Summary

"Allowing Extra Fields in Root-level Documents" does not list all situations in which an expected document is to be treated as a root-level document that allows extra fields. Sometimes (maybe always) this is documented in places where pieces of test format are specified. For example, expectedLogMessage specifies that test runners "MUST treat the log message data as a root-level document".

Also, "Allowing Extra Fields in Root-level Documents" mentions that an array of values may contain either ordinary documents or root-level documents. But it does not clearly state when it is one or the other.

Motivation

Who is the affected end user?

Driver maintainers.

How does this affect the end user?

Driver maintainers are confused, and test runner implementations do not behave the same way:

• The Java driver does not implement matching as expected by the specification: JAVA-5629.
• The C driver also does not implement matching as expected by the specification. More specifically, it incorrectly treats expectResult in expectedError as a root-level document that allows extra fields: https://github.com/mongodb/specifications/pull/1665#discussion_r1773998633.

How likely is it that this problem or use case will occur?

Some drivers have already failed to implement the "rool-level document" logic correctly. Whether or not it is caused by the specification not being explicit/clear enough is unclear.

If the problem does occur, what are the consequences and how severe are they?

A test that should have failed may pass.

Is this issue urgent?

No.

Is this ticket required by a downstream team?

No.

Is this ticket only for tests?

Yes.

Acceptance Criteria

One can find an explicit criteria / list of situations when extra fields are allowed, including extra fields in documents in arrays.