[SERVER-47702] Tests should not try to resume index builds via failpoint while a node may be in ROLLBACK Created: 22/Apr/20  Updated: 29/Oct/23  Resolved: 24/Apr/20

Status: Closed
Project: Core Server
Component/s: Replication, Storage
Affects Version/s: None
Fix Version/s: 4.7.0

Type: Bug Priority: Major - P3
Reporter: William Schultz (Inactive) Assignee: William Schultz (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-44068 Investigate the slowest sections of R... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Repl 2020-05-04
Participants:

 Description   

Some tests that use the RollbackTest fixture pause index builds and resume them on the rollback node during the kSyncSourceOperationsDuringRollback test phase. During this phase the node may be in rollback and may close client connections so running a command to set a failpoint can fail. We should resume these index builds at a point in the test when we are sure the nodes are not in ROLLBACK state.

This behavior was observed in the following tests:

  • jstests/replsets/rollback_waits_for_bgindex_completion.js
  • jstests/replsets/primary_rollbacks_before_index_build_received_votes.js.


 Comments   
Comment by Githook User [ 24/Apr/20 ]

Author:

{'name': 'William Schultz', 'email': 'william.schultz@mongodb.com', 'username': 'will62794'}

Message: SERVER-47702 Tests should not try to resume index builds against a node in ROLLBACK
Branch: master
https://github.com/mongodb/mongo/commit/fd488664298913bc37408a4443d6721da1f02ab6

Comment by William Schultz (Inactive) [ 22/Apr/20 ]

This issue turned up in a patch build while working on speeding up RollbackTest in SERVER-44068. It may have turned up since those changes affected the timing/speed of the RollbackTest transitions so made it more likely for the failpoint command to overlap with the node's entry into ROLLBACK.

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