[SERVER-57495] Increase minimum incoming wire version to 6 Created: 07/Jun/21  Updated: 23/May/23

Status: Backlog
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: David Storch Assignee: Backlog - Query Execution
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Assigned Teams:
Query Execution
Participants:

 Description   

The server currently uses a minimum incoming wire version of 0 ( RELEASE_2_4_AND_BEFORE). However, we have recently deprecated the legacy op codes (OP_QUERY, OP_INSERT, and so on) under SERVER-55788. We plan to remove support for these op codes entirely in version 5.1.0. Therefore, in order for a driver to be compatible with a 5.1.0+ server, it must support OP_MSG. A wire version of 6 (SUPPORTS_OP_MSG) indicates that the client supports the OP_MSG protocol.

As a result of this situation, it would be sensible for the server to require the incoming wire version to be at least 6. (To be more precise, the range of wire version support advertised by the client must include at least one wire version 6 or greater.) Unfortunately, we have discovered at least two officially supported driver projects with versions that support OP_MSG but did not increase their wire version to 6. This is known to be the case for PyMongo versions 3.6.x, 3.7.x and 3.8.x as well as the 3.0.x, 3.1.x, 3.2.x versions of the Node driver. If we were to require an incoming wire version of 6 in version 5.1.0 of the server, then these versions of Node and Python would break despite being 3.6 compatible releases. In order to avoid breaking these drivers, we have chosen not to make any changes to the required wire version in 5.1.0.

In a future release (perhaps 6.1.0?) we should consider making this wire version change. At this point, the server will have indeed not truly supported wire versions 0 through 5 for over a year, but we will have allowed a grace period in which clients can still depend on PyMongo 3.6.x, 3.7.x, 3.8.x and Node 3.0.x, 3.1.x, 3.2. Once a sufficiently long grace period expires, we can increase the minimum wire version as originally planned and require applications using these old-ish PyMongo and Node versions to upgrade their driver.



 Comments   
Comment by David Storch [ 11/Jan/23 ]

jeff.yemin@mongodb.com bernie@mongodb.com it's been almost another year, so I thought it would be a good time to check back in on this ticket. It's currently slated for the "7.0 Upgrade/Downgrade" project, which means that we should either decide that this change is safe to make in 7.0 or bump it another year forwards to the "8.0 Upgrade/Downgrade" project. Is it easy for you to check your numbers again regarding the number of projects using versions of PyMongo that we know would be affected by this change?

In the meantime, I'll look into whether we can amend the API Version document to clarify that wire versions 0 through 5 are not protected by the stable API.

 

Comment by Kyle Suarez [ 18/Apr/22 ]

So yes, it seems like a mistake in how API version 1 was defined, which we can go back and fix.

Let's track this work, but in a ticket separate from this one. What project should we file a ticket in? SERVER or WRITING?

Comment by David Storch [ 18/Apr/22 ]

Under the section "Other behaviors in Version 1" it includes the following: "MongoDB 5.0's reported minWireVersion (which is 0)"

Oh, I missed that! That's fascinating.

I think you are advocating for the former, i.e. that the definition of API version "1" should be changed to allow a minWireVersion in the range [0, 6]. Is that correct?

Yes. It seems like a mistake that the minWireVersions [0, 5] were included in API version 1. The scope document also says this when discussing things that are purposefully omitted from stable API version 1:

OP_INSERT, OP_UPDATE, OP_DELETE, OP_GET_MORE, and OP_KILL_CURSORS. (For several years official drivers have used OP_MSG for all operations except a connection's initial isMaster. This project does not protect pre-3.6 from breaking changes; if we drop these message types, old drivers will stop working.)

We knew explicitly when defining API v1 that we intended to get rid of these old op codes and make pre-3.6 drivers stop working. To me, this seems synonymous with dropping support for wire versions [0, 5]. So yes, it seems like a mistake in how API version 1 was defined, which we can go back and fix.

For PyMongo, there are currently around 4K projects on versions that could potentially be disrupted, and those numbers are holding pretty steady over the past six months. I'll check about other drivers, and update with results.

It turns out we were wrong about the Node driver, in a good way. Node driver 3.0 was indeed the release that shipped at the same time as MongoDB 3.6. But it did so without OP_MSG support. OP_MSG support wasn't added until 3.2.0 (the MongoDB 4.2-compatible release), at which point the maxWireVersion was bumped, all the way to 8 (4.2's maxWireVersion).

Ack, thanks for digging into this!

Comment by Jeffrey Yemin [ 15/Apr/22 ]

This is known to be the case for PyMongo versions 3.6.x, 3.7.x and 3.8.x as well as the 3.0.x, 3.1.x, 3.2.x versions of the Node driver.

It turns out we were wrong about the Node driver, in a good way.  Node driver 3.0 was indeed the release that shipped at the same time as MongoDB 3.6.  But it did so without OP_MSG support.  OP_MSG support wasn't added until 3.2.0 (the MongoDB 4.2-compatible release), at which point the maxWireVersion was bumped, all the way to 8 (4.2's maxWireVersion).

Comment by Jeffrey Yemin [ 15/Apr/22 ]

I understand why in the abstract a stable API version X would require that some range [minWireVersionY, maxWireVersionY] is always supported,

It's not abstract, though.  The Stable API scope doc (which is effectively the specification of the Stable API) includes the following two concrete statements:

  • Under the section "Other behaviors in Version 1" it includes the following: "MongoDB 5.0's reported minWireVersion (which is 0)"
  • Under the section "Breaking change" in includes the following as one of the breaking changes: "Increase isMaster.minWireVersion" 

So to make this change would require changing the definition of either Stable API version "1", or the definition of a breaking change (for any API version).

I think you are advocating for the former, i.e. that the definition of API version "1" should be changed to allow a minWireVersion in the range [0, 6].  Is that correct? 

If so, I think it's a reasonable position, as it should be compatible with any driver that supports the 3.6 wire protocol, which is going back a long way.  However, you point out that

My understanding was that we would implement this change as soon as the usage of those driver versions against the latest version of the server was sufficiently low. Also, I thought that using these driver versions against a >=5.1 server was technically not supported, but we still wanted to avoid disrupting these users.

For PyMongo, there are currently around 4K projects on versions that could potentially be disrupted, and those numbers are holding pretty steady over the past six months.  I'll check about other drivers, and update with results.

 

 

Comment by David Storch [ 07/Apr/22 ]

Right, thanks for the clarification jeff.yemin. Do you happen to know whether this change is safe for the server team to make in 6.1? I am guessing based on our previous discussions on this topic that we should probably wait a bit longer before the server bumps its minimum wire version for incoming connections from external clients to 6 (SUPPORTS_OP_MSG).

Somewhat relatedly, I suspect that after branching for 6.0 we can change the minimum wire version of internal incoming connections to 6. It is currently still specified in the server code here to be 0 (RELEASE_2_4_AND_BEFORE). Perhaps this should be tracked in a separate ticket, since it shouldn't have drivers consequences?

Comment by Jeffrey Yemin [ 07/Apr/22 ]

It would be sensible for the server to require the incoming wire version to be at least 6. (To be more precise, the range of wire version support advertised by the client must include at least one wire version 6 or greater.)

Drivers do not advertise their range of wire version support (i.e., it is not included in the hello command). Rather, drivers compare the server's advertised wire version range with their own when receiving the hello command response.

Comment by Kyle Suarez [ 07/Apr/22 ]

david.storch said we should retriage this ticket during the 6.0 release cycle, so now seems like a good time as any to send this back to the triage queue for discussion

Comment by David Storch [ 08/Sep/21 ]

I discussed this a bit further with behackett. Although using an older driver with a newer server is not officially supported, we have a test matrix showing that drivers often are forwards-compatible. This means that, for example, an application could be successfully using a 3.6-compatible driver against a 5.0 server. Such users should generally upgrade their driver to the 5.0-compatible release, but they may not be forced to do so.

We very much expect that people will attempt to use 3.6-compatible drivers against a 5.1 server. This should work, despite the removal of support for the legacy op codes, because 3.6 drivers support OP_MSG. However, because there are particular versions of PyMongo and the Node driver which do not correctly advertise wire version support for OP_MSG, the change proposed by this ticket would make it impossible to use such PyMongo and Node drivers with a 5.1 server.

Bernie gathered some numbers off Atlas, and found the following:

There are 4264 Atlas instances using one of PyMongo 3.6, 3.7 or 3.8. The vast majority of that usage is with MongoDB 4.4, with some being used with 5.0. The problem is far worse for Node 3.0.x, 3.1.x or 3.2.x. 25k+ instances with MongoDB 4.4 alone.

That means that plenty of users are likely to attempt to use a driver which does not correctly advertise OP_MSG support against a 5.1 server once 5.1 has been released. These users would experience a disruption and would have to upgrade their driver. (These users should be upgrading their drivers anyway, but we don't want to create a disruption that is not strictly necessary.)

For this reason, our current decision is not to implement this change in 5.1, and we probably shouldn't include it in 5.2 either. I am marking this "6.0 Required" so that we do not forget about it. We should re-triage this ticket sometime before the 6.0 RC cycle in order to decide whether to include this change in 6.0.

Comment by Ethan Zhang (Inactive) [ 09/Jun/21 ]

We mark it 6.0 just to remind ourselves.

Generated at Thu Feb 08 05:41:59 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.