Collation: missing collection-default inheritance coverage for aggregation stages and find query-operators/text/projection

[eerxuan]

Summary

Collation coverage in documentdb_tests/compatibility/tests/core/collation/ is broad and well-organized (command-level, collection-level default, index-level, options, resolution/precedence). However, the collection-default-collation inheritance dimension — create a collection with a default collation via CustomCollection(options={"collation": {...}}), then run a command without a collation field and verify the collection default is applied — has two concrete gaps.

Today ~61 test cases exercise collection-default inheritance, but they are concentrated on the CRUD/read commands; the aggregation pipeline and several find/projection sub-areas test command-level collation only.

Gaps

1. Aggregation stages — no collection-default inheritance tests

All 14 files under core/collation/command_level/stages/ (match, sort, group, bucket, lookup, graphlookup, geonear, unionwith, merge_out, replaceroot, accumulators, expressions, window, substages) pass collation in the command. None create a collection with a default collation and run an aggregate without collation to verify a collation-sensitive stage ($match/$sort/$group/$lookup/etc.) inherits it.

Partial existing coverage:

• core/collation/resolution/test_resolution_lookup.py exercises $lookup across collated collections.
• core/collation/collection_level/test_collection_level_propagation.py is command-level collation propagation despite the folder name (its cases all set "collation" in the command), so it does not cover collection-default inheritance.

2. find query-operators, text search, and projection — command-level only

These files have 0 collection-default cases (they test collation in the command only):

• command_level/operations/test_operations_find_query_operators.py
• command_level/operations/test_operations_find_text.py
• command_level/operations/test_operations_projection.py

No case verifies a collection's default collation is applied to a comparison/$in/regex query, $text search, or positional projection when the command omits collation.

Current coverage (for reference)

Collection-default inheritance is covered for: find (basic), count, distinct, delete, update (field/array/arrayFilters/pipeline), findAndModify (+pipeline), bulkWrite, and special collection types (capped/clustered/timeseries/views). Precedence (command collation overrides collection default) is covered in resolution/test_resolution_precedence.py and inline (e.g. test_operations_find.py).

Proposed work

Add target_collection=CustomCollection(options={"collation": {...}}) cases (command omits collation) for:

• Aggregation stages: at minimum $match, $sort, $group (_id/$addToSet), $lookup (localField/foreignField), $bucket, $graphLookup, $setWindowFields — verify each inherits the collection default.
• find with query operators ($in, $gt/$lt range, regex) inheriting the collection default.
• $text search under a collection default collation.
• Positional / computed projection under a collection default collation.
• (Optional) A precedence case per aggregation stage: collection default + command collation → command wins.

The existing CommandTestCase + CustomCollection(options=...) mechanism (see core/collation/collection_level/test_collection_level_capped.py) is the established pattern for these.

[documentdb-triage-tool]

🤖 Auto-triaged by documentdb-triage-tool.

Applied: compatibility test, enhancement
Project fields suggested: Component test-coverage · Priority P2 · Effort L · Status Triage
Confidence: 0.90 (llm)

Reasoning

LLM: Well-scoped gap in collation collection-default inheritance coverage across multiple test files (aggregation stages and find operators/text/projection), requiring new test cases across several files under compatibility/tests/core/collation/.

If a label is wrong, remove it manually and ping @patty-chow so the rules can be tuned. The bot will not re-label items that already have component labels.