Problem

SERVER-114505 adds an oplog-only command, upgradeDowngradeViewlessTimeseries, emitted during setFCV transitions across 8.x ↔ 9.0 to convert timeseries collections between their viewful form (a myts view plus a system.buckets.myts collection) and viewless form (a single myts collection).

knownCommands in mongorestore/oplog.go is a closed allowlist, so any oplog window spanning such an FCV change now aborts replay with a generic, undiagnosable error:

unknown oplog command name upgradeDowngradeViewlessTimeseries: {...}
The main exposure is PITR-style replay from an independently captured oplog (mongodump -d local -c oplog.rs followed by mongorestore --oplogReplay --oplogFile), which bypasses the admin.system.version guard in mongodump --oplog that would otherwise catch a setFCV earlier. A secondary case is a dump whose oplog range ends between the conversion entry and the admin.system.version write — it dumps successfully but cannot be restored.

Neither obvious one-line mitigation is correct:

• Allowlisting it lets it fall through to restore.ApplyOp, but filterUUIDs strips ui unless --preserveUUID is set. The server handler tripwire-asserts that the UUID is present (assertion 11450502), so this trades a tools error for a server-side assertion failure.
• Adding it to ignoredCEntries skips the conversion, leaving the target collection in its original form while subsequent oplog entries target the other form's namespace (system.buckets.myts vs myts). That risks a silently inconsistent collection.

Solution

Fail early and specifically. mongorestore should intercept the command before the generic allowlist check and report what actually happened and what to do about it:

oplog entry upgradeDowngradeViewlessTimeseries at <ts> cannot be replayed: this oplog window crosses a timeseries format conversion caused by an FCV change between 8.x and 9.0. Replaying across such a conversion is not supported. Restore an oplog range that does not span the FCV change, using --oplogLimit to stop before it if needed.