[SERVER-30799] Tailable cursor with batch size periodically returns unexpected empty batches Created: 23/Aug/17 Updated: 30/Oct/23 Resolved: 30/Aug/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | 3.5.13 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Charlie Swanson | Assignee: | Charlie Swanson |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||
| Steps To Reproduce: | Save this to a file called repro.js at the root of the mongo repository directory:
Then run:
|
||||||||||||||||||||
| Sprint: | Repl 2017-09-11 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
When a tailable cursor is used in combination with a batch size B, the semantics should be:
If using a tailable cursor against a mongod process, these are the semantics. However, if running against a mongos (which you can do with an unsharded capped collection), the last case breaks down a bit. The mongos correctly returns batches up to size B, but messes up the next getMore, incorrectly 'remembering' that the next result on that cursor should be EOF (see reproduction steps for more details). Specifically, the boolean '_eofNext' tracked within the AsyncResultsMerger is not reset on each getMore, so a full batch on one getMore will cause an empty batch on the next, even if there are more results to return. |
| Comments |
| Comment by Githook User [ 30/Aug/17 ] |
|
Author: {'name': 'Charlie Swanson', 'username': 'cswanson310', 'email': 'charlie.swanson@mongodb.com'}Message: This bug impacts tailable cursors being sent through a mongos. |
| Comment by Charlie Swanson [ 23/Aug/17 ] |
|
david.storch I'm adding this to the change streams epic since it's preventing some change stream tests from passing after implementing Seem okay to you? I have a patch that fixes it locally, but I'm working out some complications imposed by the usage of the AsyncResultsMerger in CollectionCloner, where we apparently are working with a null OperationContext. |