Overview

Time series collections whose timeField or metaField is $-prefixed could be created before v8.3. Creation of such collections is now rejected (BadValue), but a collection created on an older binary can still exist on disk after a customer upgrades. We should have test coverage proving that a pre-existing $-prefixed time series collection remains fully queryable, and that it survives a binary upgrade without becoming unreadable or breaking replication.

Background

Support for $-prefixed timeField/metaField was removed in 8.3. The $-prefix rejection lives solely in the user-facing create path (_performCollectionCreationChecks() in create_collection.cpp); it is not enforced on the applyOps/replication path (createCollectionForApplyOps()), which is what previously let these collections replicate in mixed-version clusters (see BF-40846).

The original multiversion test (timeseries_dollar_prefixed_timefield_errors.js) verified both that new $-prefixed collections are rejected and that pre-existing ones survive an upgrade and stay queryable. Under SERVER-117054 it was reduced to a single-version test that only checks the create-rejection behavior, because last-lts moved to 9.0 (>= 8.3) and the old binary can no longer create the collections to begin with. The "stays queryable / survives upgrade" coverage was dropped as a result.

Proposed Coverage

1. A single-version test that injects a $-prefixed time series collection without going through create validation (the applyOps create path bypasses the $-prefix check — confirmed by the CreateCollectionForApplyOpsTimeseriesDollarPrefix unit test), then asserts the collection is queryable and writable.
2. Optionally, a multiversion test that recreates the upgrade scenario by injecting such a collection on the starting binary (again via applyOps, since create is now rejected everywhere), then upgrades and asserts it remains queryable.

Open Question For Triage

Is the ongoing maintenance cost of this coverage justified, given $-prefixed collections are a legacy edge case? If we decide the on-disk/binary-compatibility guarantee is worth protecting against regressions, item (1) is low-cost and low-maintenance; item (2) is more valuable but carries the usual multiversion-test upkeep.