[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: |
|
||||||||||||||||
| 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: The aggregate command resolves all views to their backing collections, This fix robustifies view_cycle_catalog_lookup.js so that it tolerates (cherry picked from commit 3406454039941a8ec1ff700fb6c3377ec6e5c5bc) |
| Comment by Githook User [ 29/Jun/18 ] |
|
Author: {'username': 'ksuarz', 'name': 'Kyle Suarez', 'email': 'kyle.suarez@mongodb.com'}Message: The aggregate command resolves all views to their backing collections, This fix robustifies view_cycle_catalog_lookup.js so that it tolerates |
| 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 |