[SERVER-59105] Remove parsing of 'canThrowSSVOnIgnored' Created: 04/Aug/21  Updated: 06/Dec/22  Resolved: 03/Feb/22

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

Type: Task Priority: Major - P3
Reporter: Marcos José Grillo Ramirez Assignee: [DO NOT USE] Backlog - Sharding EMEA
Resolution: Won't Do Votes: 0
Labels: shardingemea-qw
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-63269 Remove positional parsing of canThrow... Closed
related to SERVER-65530 Get rid of all legacy ChunkVersion pa... Closed
Assigned Teams:
Sharding EMEA
Participants:

 Description   

Due to backward compatibility reasons, a router on version 5.0 will send the parameter as true even though it is not taken into account, this means that shards with latest versions must attempt to parse and ignore the parameter (in case there is a router with 5.0), but are under no obligation to send it. On the next major release we can completely remove the parsing.



 Comments   
Comment by Marcos José Grillo Ramirez [ 27/Sep/21 ]

>> Is the position of the boolean field always fixed at the 3rd position and the timestamp on the 4th position?

Yes

>> I.e., in master (6.0) is the format like this currently: [major|minor, epoch, canThrowSSVOnIgnored (never missing, always true), timestamp (never missing)] ?

No, in master (6.0) is:

[major|minor, epoch, timestamp (never missing)]

But in 5.0 is:

[major|minor, epoch, canThrowSSVOnIgnored (always true), timestamp (never missing)]

So, the compatibility problem would surface in mixed versions.

Comment by Kaloian Manassiev [ 20/Sep/21 ]

Ah, yes, now I get it. The problem is with the positions of the values, because they are sent as an array and not as fields in a BSON object. Is the position of the boolean field always fixed at the 3rd position and the timestamp on the 4th position?

I.e., in master (6.0) is the format like this currently: [major|minor, epoch, canThrowSSVOnIgnored (never missing, always true), timestamp (never missing)] ?

Comment by Marcos José Grillo Ramirez [ 20/Sep/21 ]

In the presence of mixed versions, a 6.0 mongod can have two possible scenarios:

  • A 5.0 router which will send the boolean and the timestamp
  • A 6.0 router which will send the timestamp

If we throw out the parsing of the boolean, everything will work fine with a 6.0 router, but, with a 5.0 router, we'll mistakenly parse the boolean as a timestamp. The main problem is that the structure is an array and we added yet another field (the timestamp) at the end. Does it make sense kaloian.manassiev?

Comment by Kaloian Manassiev [ 13/Sep/21 ]

Didn't we add that field being sent as `true` from 4.4.0 onwards, and 4.4.0 shards are parsing it in order to make sure they don't throw SSV to a 4.2 router? If that is the case, then we can just throw out the parsing as of 5.0, right?

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