[SERVER-31015] Investigate if GetMoreRequest must include readConcern for tailable cursors Created: 08/Sep/17 Updated: 27/Oct/23 Resolved: 14/Sep/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying, Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Misha Tyulenev | Assignee: | Backlog - Query Team (Inactive) |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Assigned Teams: |
Query
|
||||
| Operating System: | ALL | ||||
| Participants: | |||||
| Linked BF Score: | 0 | ||||
| Description |
|
The scenario that fails is described in BF-6485, the cursors are consistent because because the cursor is the find and getMore is an implementation detail. However the tailable cursors may need the support of readConcern |
| Comments |
| Comment by Andy Schwerin [ 11/Sep/17 ] |
|
getmore operations don't need read concern because they inherit the concern from the cursor. All we promised was that the cursor contents are from after the time sent on the find or aggregate. This is normally fine because getmore is an implement detail, invisible below the driver. Maybe get more should reject rather than ignore read concern. I'd welcome argument on why tailable cursors are special. |
| Comment by Charlie Swanson [ 11/Sep/17 ] |
|
This sounds like a legit bug to me. Is this also a bug with readConcern "majority" where a getMore might see operations that aren't majority committed? That would be a problem... cc david.storch - this looks like another bug where we fail to serialize some of the options sent to mongos, not sure if this should move over to the query team. |
| Comment by Misha Tyulenev [ 08/Sep/17 ] |
|
charlie.swanson , schwerin what do you think? |