[SERVER-59085] Remove _isSelf/saslStart/saslContinue/buildinfo/authenticate from allowlist for OP_QUERY commands Created: 03/Aug/21 Updated: 22/Nov/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Yoon Soo Kim | Assignee: | Backlog - Query Execution |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Query Execution
|
||||||||
| Backwards Compatibility: | Major Change | ||||||||
| Participants: | |||||||||
| Description |
|
At the very late stage of PM-912 project, we realized that repl code is sending _isSelf/saslStart/saslContinue as OP_QUERY commands (see We should remove _isSelf/saslStart/saslContinue/buildinfo/authenticate OP_QUERY commands from allowlist for the v6.0 release. To remove saslStart/saslContinue/buildinfo/authenticate, we may need to coordinate the efforts with drivers team since some drivers are using them. |
| Comments |
| Comment by David Storch [ 12/May/23 ] |
|
I noticed that this was marked with a "7.0 Desired" fixVersion, but there are no plans for it to go into 7.0. Marking this for re-triage. We could choose to just close it or to work with drivers to figure out a safe plan for making this change that wouldn't affect users (unless perhaps they were using extremely old driver versions). |
| Comment by Jeffrey Yemin [ 27/Jan/22 ] |
|
I recommend that we defer this work until API Version "2" due to a few facts on the ground:
|
| Comment by David Storch [ 26/Jan/22 ] |
|
I'm marking this ticket to be re-triaged. We should not do this in 6.0 so that pre-existing drivers which use OP_QUERY to authenticate will keep working with a 6.0 server. However, we should consider doing this in some future release where the server need not be compatible with such older drivers. |
| Comment by Yoon Soo Kim [ 10/Aug/21 ] |
|
Would it be possible to try OP_MSG-based connection handshake first and if it fails, we fall back to OP_QUERY-based connection handshake? Do we know the percentage of 3.4 and older servers? |
| Comment by David Storch [ 10/Aug/21 ] |
|
ethan.zhang I don't think it's worth filing a follow-up project. We've achieved the most of the code simplifications that we set out to do. The remaining work which we've chosen to cut is quite minor, with the exception of SERVER-58491. The remaining work can be scheduled via quick wins, neweng, or simply not scheduled at all. This particular ticket is in a different category because it cannot be done for correctness reasons at least until at least after releasing the 6.0 LTS release. |
| Comment by Ethan Zhang (Inactive) [ 10/Aug/21 ] |
|
david.storch Now seeing this and some other tickets being removed from PM-912 I start to think maybe we should create another PM ticket to group them together. Like a follow-up project. Do you think that makes sense? Or I can see them go to the quick win epic as well. |