[CDRIVER-3563] Cursor may use an invalidated server description Created: 10/Mar/20 Updated: 27/Oct/23 Resolved: 27/Jun/23 |
|
| Status: | Closed |
| Project: | C Driver |
| Component/s: | libmongoc |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Kevin Albertson | Assignee: | Kevin Albertson |
| Resolution: | Gone away | Votes: | 0 |
| Labels: | FY21Q4, planned-maintenance-detectable-bug | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Epic Link: | Improve Developer Experience | ||||||||||||||||||||
| Quarter: | FY24Q2 | ||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||
| Description |
|
Since a mongoc_cursor_t ties itself to a server_id, it is currently possible that it may attempt to send a command using a server description that has been marked as UNKNOWN. I have been able to reproduce such a situation by modifying example-client.c. Here is the salient bit:
This prints:
The test case forces a server being marked as UNKNOWN. But I believe this can happen in a two situations: This bug is extremely similar to |
| Comments |
| Comment by Kevin Albertson [ 27/Jun/23 ] |
|
I am unable to reproduce the same error in C driver 1.24.1 with these tests: https://github.com/mongodb/mongo-c-driver/compare/master...kevinAlbs:mongo-c-driver:C3563?expand=1
|
| Comment by Jeremy Mikola [ 11/Jun/20 ] |
|
This may be relevant to Sending an equivalent command for the second attempt in the Retryable Reads spec, which addresses whether drivers can simply send the same command to the newly selected server for the retry attempt. I think this (and the issue at hand) is relevant to any helper that creates a synthetic cursor before communicating with the server. With respect to aggregate, the server selection is just happening to perform wire version checks and validate options, the errors from which are relayed through the first mongoc_cursor_error call before mongoc_cursor_next kicks off the command. I don't believe it applies to the traditional find case, as that cursor is derived from a server response and we needn't worry about retrying getMore commands today. |