[SERVER-78877] Why do 'find' and 'aggregate' commands represent maxTimeMS differently? Created: 11/Jul/23  Updated: 10/Nov/23  Resolved: 10/Nov/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 7.3.0-rc0

Type: Improvement Priority: Major - P3
Reporter: David Percy Assignee: James Harrison
Resolution: Fixed Votes: 0
Labels: neweng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by COMPASS-7440 Investigate changes in SERVER-78877: ... Needs Triage
is depended on by TOOLS-3418 Investigate changes in SERVER-78877: ... Closed
Documented
is documented by DOCS-16488 Investigate changes in SERVER-78877: ... Backlog
Assigned Teams:
Query Optimization
Backwards Compatibility: Fully Compatible
Sprint: QO 2023-10-02, QO 2023-10-16, QO 2023-10-30, QO 2023-11-13
Participants:

 Description   

Currently FindCommandRequest and AggregateCommandRequest represent maxTimeMS differently:

Not only is the C++ type different, but also the BSON type and the parsing/validation rules are different. For simplicity, can we make them the same? Especially since we translate 'find' requests to 'aggregate' (for views), you would think they have the same set of valid values.

Looks like the last ticket to touch this was SERVER-54925, so there may be more discussion or explanation there.



 Comments   
Comment by Githook User [ 19/Oct/23 ]

Author:

{'name': 'James Harrison', 'email': '00jamesh@gmail.com', 'username': 'jameseh96'}

Message: SERVER-78877 Make find/count maxTimeMS consistent with aggregate equivalent
Branch: master
https://github.com/mongodb/mongo/commit/d169f5ea1f275adbae4300825d2d4135f48cbb83

Comment by James Wahlin [ 25/Sep/23 ]

I don't know of a reason not to support a 64 bit integer across the board. We wouldn't consider this a breaking API change as no one should be relying on > int_32t values returning an error.

Comment by James Harrison [ 25/Sep/23 ]

james.wahlin@mongodb.com What are your thoughts on this?

I'm not sure if applying the proposed change to maxTimeMS for count would count as a breaking change to the API, or if there's a specific reason it was required to be int32_t before.

Generated at Thu Feb 08 06:39:31 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.