[SERVER-85890] Oplog application of dbcheck batch entry can fassert if namespace was collection that is recreated as view Created: 29/Jan/24  Updated: 06/Feb/24

Status: Open
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Huayu Ouyang Assignee: Moustafa Maher
Resolution: Unresolved Votes: 0
Labels: pm-855-milestone-3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Operating System: ALL
Sprint: Repl 2024-02-19
Participants:
Linked BF Score: 127

 Description   

From BF-31587, this sequence of events can occur:
1. Create a collection with namespace “a” at time 1
2. Start dbcheck at time 2
3. Drop the collection at time 3
4. Create a view with namespace “a” at time 4
5. Primary dbcheck oplog entry at time 5 for namespace “a”, but with read timestamp at time 2 (while namespace “a” is a collection)
6. Secondary tries to apply this dbcheck oplog entry at time 5, but during general oplog application code (before we reach the dbcheck specific code), we check if the namespace is a view or not. This seems to be done with no read timestamp (set here), so then we fassert because this namespace is a view and applyOps is not allowed on a view.

We should look into if we can skip the fassert if the operation is dbcheck, as once we reach the dbcheck specific code, the secondary should then use correct read timestamp at time 2, when the namespace was still a collection. But we should double check if we are always guaranteed to get the stashed catalog at our requested read timestamp. If not, we should modify the secondary to catch the error and log the same warning message about the CommandNotSupportedOnView as we do on the primary


Generated at Thu Feb 08 06:58:52 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.