[SERVER-83801] Allow command to get Interrupted error code in timeseries_insert_idle_bucket_expiration.js Created: 01/Dec/23 Updated: 01/Dec/23 Resolved: 01/Dec/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Jiawei Yang | Assignee: | Jiawei Yang |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Operating System: | ALL |
| Sprint: | Repl 2023-12-11 |
| Participants: |
| Comments |
| Comment by Jiawei Yang [ 01/Dec/23 ] |
|
gregory.noma@mongodb.com Right, we are not getting InterruptedDueToReplStateChange showing that the failed tests are not caused by stepdown killOp directly. I think in general we could get Interrupted for an user command but I'm not sure for this particular timeseries test, what is the reason we got ErrorCode::Interrupted during May and June. It could be we had a bug during that time. |
| Comment by Gregory Noma [ 01/Dec/23 ] |
|
jiawei.yang@mongodb.com I don't think getting Interrupted is expected here. Since there are stepdowns I would expect InterruptedDueToReplStateChange, but not Interrupted. Notably, if a driver receives InterruptedDueToReplStateChange it will retry the operation on the new primary, but for Interrupted it will simply return the error to the user. If Interrupted were expected, then either the driver would have to handle that error or basically every single test would have to tolerate it in stepdown test suites. Since we don't do either of those, I think that indicates that receiving Interrupted is a bug. |