[SERVER-58346] Calculate generic WireVersion enum constants Created: 07/Jul/21  Updated: 29/Oct/23  Resolved: 09/Aug/21

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

Type: Task Priority: Major - P3
Reporter: Xuerui Fa Assignee: Xuerui Fa
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Backwards Compatibility: Fully Compatible
Sprint: Repl 2021-08-09, Repl 2021-08-23
Participants:

 Description   

Today, the WireVersion enum is like this:

enum WireVersion {
    RELEASE_2_4_AND_BEFORE = 0,
    ... some semantically significant wire versions ...
    // Supports resumable initial sync (4.4+).
    RESUMABLE_INITIAL_SYNC = 9,
    WIRE_VERSION_47 = 10,
    WIRE_VERSION_48 = 11,
    WIRE_VERSION_49 = 12,
    WIRE_VERSION_50 = 13,
    LATEST_WIRE_VERSION = WIRE_VERSION_50,
    LAST_CONT_WIRE_VERSION = LATEST_WIRE_VERSION - 1,
    LAST_LTS_WIRE_VERSION = RESUMABLE_INITIAL_SYNC,
};

Remove all values starting with WIRE_VERSION_47. These values are used only by class WireSpec to determine if an incoming client is compatible with this server, and to fill out the min/maxWireVersion fields of the "hello" reply.

Instead, calculate the latest, last rapid, and last major wire versions at runtime from the generated kNumberOfReleasesSince44 constants. For example, the latest wire version is RESUMABLE_INITIAL_SYNC + kNumberOfReleasesSince44.



 Comments   
Comment by Xuerui Fa [ 12/Jan/22 ]

Sorry, I was being unclear! We are currently developing 5.3, so master is 5.3 and its wire version is 16.

You're correct that 4.5 never received a wire version. The project that implemented this change, PM-2091, did not modify previous behavior, so we decided to maintain that in the new implementation. releases.yml is indeed the source of truth and is used to calculate multiversion::kSince_4_0.

Comment by Jeremy Mikola [ 12/Jan/22 ]

xuerui.fa: I do have a follow-up question. You said:

So since we just released v5.3, the latest wire version is currently 16.

Does that mean that 5.3 reports wire version 16? Or since 5.3 has been tagged, the master branch reports 16 and a 5.3 release would report 15? It looks like a 5.3 branch has yet to be created, so perhaps 5.3 and master are one and the same in this respect – in which case 5.3 is 16.

I understand 5.0 is historically wire version 13 and that will not change. But if server versions 5.1 and later now calculate the latest wire version as REPLICA_SET_TRANSACTIONS + multiversion::kSince_4_0 (where REPLICA_SET_TRANSACTIONS is 7), it's still a bit unclear as to how multiversion::kSince_4_0 is calculated.

For the math to work out such that 5.3 reports wire version 16, multiversion::kSince_4_0 would need to be 9. I think that works if we pretend that 4.5 never existed:

  • 4.2
  • 4.4
  • 4.7
  • 4.8
  • 4.9
  • 5.0
  • 5.1
  • 5.2
  • 5.3

It sounds like that's the case. If it's not too much trouble, can you sanity check me on determining how the 4.5 release is actually ignored? I originally assumed that releases.h.tpl was generated from git tag information, it looks like the actual source of truth is a releases.yml file passed as a command-line argument. If so, I suppose 4.5 is just never mentioned in that file.

Digging a bit further in the server repository, I did find src/mongo/util/version/releases.yml, so perhaps that's our new source of truth. It does omit 4.5 as I would have expected.

Comment by Xuerui Fa [ 12/Jan/22 ]

jmikola Yes, I believe your three points are correct. Going forward, the wire version will be incremented by 1 for each release, including rapid releases for continuous delivery. So since we just released v5.3, the latest wire version is currently 16.

I think wrt the previous wire versions, I believe everything from 4.5-4.9 was consider an internal release to test continuous delivery. I'm not sure why we don't have a wire version for 4.5, leading to 13 instead of 14 for 5.0, but going forward we will definitely increment once per tagged release version.

Feel free to ping me if you have any other questions!

Comment by Jeremy Mikola [ 11/Jan/22 ]

xuerui.fa: I've been tasked with investigating the downstream impact for drivers here. Drivers engineers have historically looked to wire_version.h for determining the exactly wire version for each server release. For added context, drivers use wire versions to detect support for various server features (e.g. wireversion-featurelist.rst).

I noted that mongodb/mongo@efdac64 for SERVER-59012 more recently changed wire_version.h to calculate LATEST_WIRE_VERSION from the number of releases since 4.0 (instead of 4.4). It looks like multiversion::kSince_4_0 is generated from src/mongo/util/version/releases.h.tpl so there isn't a specific file we can look to for the exact value.

Going forward, it seems as if driver engineers will need to manually calculate this for each release. We already keep a record in wireversion-featurelist.rst, so I expect that will just become our authoritative reference. That said, I do want to confirm a few things:

  • Wire versions reported in hello responses will now increment by one for each passing release
  • Drivers can still rely on new features (at least those significant enough that we'd need to detect them) only being introduced with a wire version bump corresponding to a new minor release.
  • All tagged minor releases will be relevant for counting future wire version increments.

With regard to the last bullet: In the past, there were cases of larger wire version bumps between public releases. Using 4.4 (wire version 9) and 5.0 (wire version 13) as an example, it's not clear to me how that would have been calculated using this new system. There were four tagged minor versions between 4.4 and 5.0 (4.5, 4.7, 4.8, and 4.9), which would suggest wire version 14 for 5.0. I understand this new calculation only applies going forward (5.1+), so hopefully this isn't anything we'll need to worry about with the new quarterly/LTS release schedule.

Comment by Vivian Ge (Inactive) [ 06/Oct/21 ]

Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you!

Comment by Githook User [ 09/Aug/21 ]

Author:

{'name': 'XueruiFa', 'email': 'xuerui.fa@mongodb.com', 'username': 'XueruiFa'}

Message: SERVER-58346: Calculate generic WireVersion enum constants
Branch: master
https://github.com/mongodb/mongo/commit/eb1a10b7c69e5d46ea3f7e1afaa427a3c5032fe7

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