[SERVER-51653] Ban uses of unstable command parameters with apiStrict: true Created: 15/Oct/20 Updated: 29/Oct/23 Resolved: 02/Dec/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 4.9.0 |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | A. Jesse Jiryu Davis | Assignee: | Arun Banala |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | qopt-team | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Sprint: | Query 2020-11-30, Query 2020-12-14 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
In the "API Version Testing" project we added a boolean field "unstable" to mark command parameters in the IDL for API Version 1 commands. Unstable parameters are not guaranteed to be backward-compatible, even though they are parameters of V1 commands. We plan to use the "unstable" field only when comparing old and new releases' IDL definitions of V1 commands; we'll ignore incompatible changes to unstable fields. However, arun.banala makes a good suggestion: at runtime, ban the use of unstable parameters in client requests that include apiStrict: true. |
| Comments |
| Comment by Githook User [ 02/Dec/20 ] | |||||||||||||||||||||||||||||||||||||||
|
Author: {'name': 'Arun Banala', 'email': 'arun.banala@mongodb.com', 'username': 'banarun'}Message: | |||||||||||||||||||||||||||||||||||||||
| Comment by Steven Vannelli [ 19/Oct/20 ] | |||||||||||||||||||||||||||||||||||||||
|
Thanks arun.banala. I'm adding this to that project and assigning it to the Query backlog user for now. | |||||||||||||||||||||||||||||||||||||||
| Comment by A. Jesse Jiryu Davis [ 15/Oct/20 ] | |||||||||||||||||||||||||||||||||||||||
|
I'm not sure how to do this. The IDL compiler might generate code that checks for unstable parameters, e.g. from the following IDL:
... we might generate:
Then in TypedCommand:
|