[SERVER-44126] Make AsyncResultsMerger only swallow retriable errors Created: 21/Oct/19 Updated: 06/Nov/19 Resolved: 06/Nov/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Cheahuychou Mao | Assignee: | Bernard Gorman |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Sprint: | Query 2019-11-18 | ||||||||
| Participants: | |||||||||
| Description |
|
When allowPartialResults is true, establishCursors (i.e. the find command) only swallows RetriableError and FailedToSatisfyReadPreference errors. However, it looks like AsyncResultsMerger (i.e. the getMore command) swallows all kinds of errors. It should be changed to swallow only retriable errors. |
| Comments |
| Comment by Bernard Gorman [ 06/Nov/19 ] |
|
I don't think this change makes sense. The reason we only swallow retriable errors (or FailedToSatisfyReadPreference) in establishCursors is that they indicate a transient failure; we automatically retry on seeing these exceptions, and only surface them in establishCursors when we have exhausted our maximum retry attempts. These are exceptions like HostUnreachable, NetworkTimeout etc that are mostly only relevant when attempting to establish an initial connection. But since we aren't going to try to re-establish a connection that's dropped by the ARM, limiting allowPartialResults' tolerance to only retriable errors doesn't make sense here. We should continue to observe allowPartialResults regardless of what caused us to disconnect. |