[GODRIVER-1252] Have RunCommandCursor implement retryable read Created: 25/Aug/19 Updated: 27/Mar/23 |
|
| Status: | Backlog |
| Project: | Go Driver |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | David Golden | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
Because RunCommandCursor returns a cursor, we know the command is a read command, so it would help users who implement custom read commands with it to have it implement retryable reads. This is encouraged by the retryable reads spec, which says:
In the short term, it would also help tools/mongomirror implement custom find commands without implementing their own retryable read logic. |
| Comments |
| Comment by Divjot Arora (Inactive) [ 16/Sep/19 ] |
|
To summarize an offline conversation with david.golden: we're ok with having this functionality. This isn't very high priority for the tools team and they're willing to submit a PR when it's prioritized on their end, so I'm going to leave this as "Open" for now. |
| Comment by David Golden [ 26/Aug/19 ] |
|
I think if it would error anyway with anything that doesn't return a cursor, I don't think there's much risk. In normal usage, it wouldn't ever be used for anything other than a read command that returns a cursor so assuming that it's being used correctly seems reasonable to me. The odds that someone is using it incorrectly (and ignoring the error) and experiencing a retryable error seem vanishingly small, so the risk of repeating a write seem acceptable. If they are ignoring errors and not noticing incorrect usage, then the duplicate write error is their fault, not the driver's. |
| Comment by Divjot Arora (Inactive) [ 26/Aug/19 ] |
|
david.golden I think this sounds like a reasonable idea, but RunCommandCursor doesn't do any introspection of the command document. A user could use it to accidentally run a write command and wouldn't know of the error until after the command is finished running. Given that the method is part of our supported public API, it seems risky to add retryability to it. Thoughts? |