[SERVER-79308] mongod and mongos change streams treat maxTimeMS differently Created: 25/Jul/23 Updated: 08/Aug/23 Resolved: 08/Aug/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Mickey Winters | Assignee: | Backlog - Query Execution |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Query Execution
|
| Participants: |
| Description |
|
the behavior I seemed to observe is that mongod will ignore maxTimeMS. even if its lower than maxAwaitTimeMS it won't timeout the query. but on mongos it will hit a timeout if mongod doesn't respond before maxTimeMS. in the spirit of reducing behavior differences between replSets and sharded clusters we should fix this to have just one behavior. I tested this with 7.1 sharded/unsharded and 5.0 sharded/unsharded. and it seems 7.1 was the only one where it errored |
| Comments |
| Comment by Amr Elhelw [ 08/Aug/23 ] |
|
Closing this issue since Bernard could not reproduce this. |
| Comment by Mickey Winters [ 26/Jul/23 ] |
|
that makes sense. I guess my question now is more, do we want to change the behavior of mongod or mongos here to have less differences in behavior for invisible sharding, or are we just fine with leaving the difference. if a customer was specifying maxTimeMS and it was ignored and we secretly migrate them to a sharded cluster then suddenly their change stream would start erroring potentially |