[SERVER-35634] view_catalog_cycle_lookup.js should not always assert that finds on views will succeed Created: 15/Jun/18  Updated: 29/Oct/23  Resolved: 29/Jun/18

Status: Closed
Project: Core Server
Component/s: Aggregation Framework
Affects Version/s: None
Fix Version/s: 4.0.1, 4.1.1

Type: Improvement Priority: Major - P3
Reporter: Kyle Suarez Assignee: Kyle Suarez
Resolution: Fixed Votes: 0
Labels: read-only-views
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Related
is related to SERVER-35635 Use AutoGetCollection::ViewMode::kVie... Backlog
Backwards Compatibility: Fully Compatible
Backport Requested:
v4.0
Sprint: Query 2018-07-02, Query 2018-07-16
Participants:
Linked BF Score: 15

 Description   

view_catalog_cycle_lookup.js continually remaps views to views, views to collection, and then reads from views. In the readFromView state, it asserts that a find on a view will always succeed. However, the aggregation command releases the collection lock before creating and iterating the cursor. In this short window of time, it's possible that a collection was dropped and replaced with a view. Then, DocumentSourceCursor::loadBatch() will throw upon acquiring locks because the underlying namespace is a view, not a collection.

This ticket is a request to change the test to be more resilient to these types of failures.



 Comments   
Comment by Githook User [ 29/Jun/18 ]

Author:

{'username': 'ksuarz', 'name': 'Kyle Suarez', 'email': 'kyle.suarez@mongodb.com'}

Message: SERVER-35634 view cycle test should not always assert that finds will succeed

The aggregate command resolves all views to their backing collections,
then re-runs the command so that no views are present. However, it
releases the collection lock before creating and iterating the cursor.
In this window of time, one of the involved collections may be dropped
and replaced with a view.

This fix robustifies view_cycle_catalog_lookup.js so that it tolerates
this situation, as it is expected for the command to fail.

(cherry picked from commit 3406454039941a8ec1ff700fb6c3377ec6e5c5bc)
Branch: v4.0
https://github.com/mongodb/mongo/commit/bb7533cf0d5886e3eafe8b419dafb82135145a3a

Comment by Githook User [ 29/Jun/18 ]

Author:

{'username': 'ksuarz', 'name': 'Kyle Suarez', 'email': 'kyle.suarez@mongodb.com'}

Message: SERVER-35634 view cycle test should not always assert that finds will succeed

The aggregate command resolves all views to their backing collections,
then re-runs the command so that no views are present. However, it
releases the collection lock before creating and iterating the cursor.
In this window of time, one of the involved collections may be dropped
and replaced with a view.

This fix robustifies view_cycle_catalog_lookup.js so that it tolerates
this situation, as it is expected for the command to fail.
Branch: master
https://github.com/mongodb/mongo/commit/3406454039941a8ec1ff700fb6c3377ec6e5c5bc

Comment by Kyle Suarez [ 18/Jun/18 ]

I think can be done. We could still assert.always(), but if it fails, check that the error code is ErrorCodes::CommandNotSupportedOnView (or, if we do SERVER-35635, I think the error would be ErrorCodes::OperationFailed) and ignore it. We use ErrorCodes::GraphContainsCycle when an illegal cycle is created, which is a clear signal that something went awfully wrong.

Comment by Max Hirschhorn [ 18/Jun/18 ]

The view_catalog_cycle_lookup.js FSM workload is the only test that detected the issue described in SERVER-35130 with the interaction between reloading the view catalog and secondary reads leading to an inconsistent in-memory view catalog. I'd want to ensure it is still possible to detect that issue if we are going to weaken the assertions in the view_catalog_cycle_lookup.js FSM workload.

Generated at Thu Feb 08 04:40:27 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.