[SERVER-60947] concurrency_sharded_replication_multiversion_passthrough does not set coordinateCommitReturnImmediatelyAfterPersistingDecision to false for binaries in last version Created: 22/Oct/21  Updated: 27/Oct/23  Resolved: 07/Feb/23

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

Type: Bug Priority: Major - P3
Reporter: Randolph Tan Assignee: Tausif Rahman (Inactive)
Resolution: Gone away Votes: 0
Labels: sharding-nyc-subteam3, sharding-wfbf-day
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
related to SERVER-72929 Make resmoke fixtures compatible with... Closed
is related to SERVER-63971 Change server parameter to default to... Closed
Assigned Teams:
Server Development Platform
Operating System: ALL
Sprint: Sharding 2022-02-21, DAG 2022-05-16
Participants:
Linked BF Score: 0
Story Points: 1

 Description   

This causes race conditions in the tests when it tries to read the result of the previous write done by a transaction.



 Comments   
Comment by Tausif Rahman (Inactive) [ 07/Feb/23 ]

Since this ticket is no longer needed (SERVER-63971 has had an equivalent effect), I'm going to close this out & it should take BF-23000 and BF-24325 with it. As mentioned by max.hirschhorn@mongodb.com, we have SERVER-72929 to address the underlying issue which will be done as part of PM-3104. I added some notes on these related tickets to SERVER-72929. If there are any concerns, feel free to reach out.

Comment by Max Hirschhorn [ 07/Feb/23 ]

Is this still a problem? Looks like there hasn't been much movement in the last year.

Yes and no.

  • No there won't be more Evergreen failures around the coordinateCommitReturnImmediatelyAfterPersistingDecision server parameter not getting set to false by resmoke. This is because SERVER-63971 reverted the production-default value of the coordinateCommitReturnImmediatelyAfterPersistingDecision server parameter to be false again for other reasons. It therefore doesn't matter that resmoke skips setting the testing-default value of the coordinateCommitReturnImmediatelyAfterPersistingDecision server parameter in multiversion testing because it happens to be setting the same value as the production-default anyway.
  • Yes the design of using git checkout as a mode for configuring multiversion testing is still flawed in the way described in my earlier comment. Solving this is part of the scope for PM-3104.
Comment by Alex Neben [ 07/Feb/23 ]

Is this still a problem? Looks like there hasn't been much movement in the last year.

Comment by Max Hirschhorn [ 06/Mar/22 ]

Posting the results of the Slack investigation I had done to Jira:

maxh: Does _builder.py actually load the version of the fixture/ directory from the last-lts branch into the current python interpreter? I see some references to load_all_modules(). That seems kind of broken to me because the definition of LAST_LTS_MONGOD_BINARY is different between branches and means the default textual interpretation is wrong.

maxh: I feel like at least knowing that we're using the v5.0 version of the fixture/ directory with the v5.0 definition of LAST_LTS_MONGOD_BINARY in mongodb-mongo-master at least restores my sanity as to why the mongod-5.0 invocation is missing only receiveChunkWaitForRangeDeleterTimeoutMS and coordinateCommitReturnImmediatelyAfterPersistingDecision along with using DEFAULT_EVERGREEN_LAST_LTS_MONGOD_LOG_COMPONENT_VERBOSITY. Those are all the parameters which are controlled by self.config.LAST_LTS_MONGOD_BINARY.

maxh: Basically mongodb-mongo-master is accidentally configuring binVersion 5.0 as if it were mongodb-mongo-v5.0 configuring binVersion 4.4. Instead the design probably intended to configure binVersion 5.0 as if it were mongodb-mongo-v5.0 configuring binVersion 5.0 (aka latest from that Evergreen project's perspective).

Comment by Jason Zhang [ 09/Feb/22 ]

It looks like this is an issue with the task generation not setting coordinateCommitReturnImmediatelyAfterPersistingDecision to false for the necessary binaries. Since it seems to be more in the task generation code I think it might be appropriate to reassign this ticket. robert.guo

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