[SERVER-47911] Prevent stale_mongos_and_restarted_shards_agree_on_shard_version.js from running in sharding_multiversion Created: 03/May/20  Updated: 29/Oct/23  Resolved: 12/May/20

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

Type: Task Priority: Major - P3
Reporter: Max Hirschhorn Assignee: Kaloian Manassiev
Resolution: Fixed Votes: 0
Labels: PM-1645-Milestone-1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-47822 Re-enable sharding multiversion suites Closed
Related
is related to SERVER-45779 Throw Stale Shard Version when collec... Closed
is related to SERVER-47556 AutoGetCollectionForReadCommand: Conv... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding 2020-05-18
Participants:
Linked BF Score: 15

 Description   

It is currently testing behavior known to not work correctly on the 4.4 branch.



 Comments   
Comment by Githook User [ 12/May/20 ]

Author:

{'name': 'Kaloian Manassiev', 'email': 'kaloian.manassiev@mongodb.com', 'username': 'kaloianm'}

Message: SERVER-47911 Prevent 'stale_mongos_and_restarted_shards_agree_on_shard_version.js' from running in the multiversion suites
Branch: master
https://github.com/mongodb/mongo/commit/e2602ad053b2120982fbcac8e33e1ad64e6ec30a

Comment by Max Hirschhorn [ 04/May/20 ]

I will fix it today.

kaloian.manassiev, it isn't so urgent because the sharding_multiversion task isn't running in Evergreen until we do SERVER-47822.

Should the fix be to just add requires_fcv_44, or is there a better way to express that it requires a binary version of 4.4 (latest-stable), which contains a certain backport? I guess the latter is difficult to express, so probably can't be done.

I believe etc/backports_required_for_multiversion_tests.yml can actually be used to express not running the test in sharding_multiversion on the master branch until the 4.4 branch has the same ticket(s) backported to it. Tests with the requires_fcv_46 tag on the master branch wouldn't hit the issue with burn_in_tests described in SERVER-47136 though. I figured since you were going to do the backports en masse it wouldn't be as hard to remember to remove the requires_fcv_46 tag everywhere afterwards.

Comment by Kaloian Manassiev [ 04/May/20 ]

This is my mistake, sorry. I removed this tag, because I couldn't explain to myself why would this functionality depend on the FCV, but just the binary version, but didn't consider the multi-version tests.

I will fix it today.

Should the fix be to just add requires_fcv_44, or is there a better way to express that it requires a binary version of 4.4 (latest-stable), which contains a certain backport? I guess the latter is difficult to express, so probably can't be done.

Comment by Max Hirschhorn [ 03/May/20 ]

kaloian.manassiev, I noticed you removed the requires_fcv_44 tag in the changes from 9771a6d as part of SERVER-47556, even though SERVER-45779 which introduced this test has yet to be backported to the 4.4 branch. I would think we'd want to have this test be tagged with requires_fcv_46 on the master branch until more of the changes in PM-1645-Milestone-1 are backported to the 4.4 branch.

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