[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:
Depends
is depended on by TOOLS-2343 use readOnce cursor option in collect... Closed

 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:

Any driver that provides generic command runners for read commands(with logic to inherit a client-level read concerns) SHOULD implement retryability for the read-only command runner.

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?

Generated at Thu Feb 08 08:36:01 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.