Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-50972

Make tenant migration donor startup recovery more likely to cover all the 4 possible states

    • Fully Compatible
    • Sharding 2020-09-21, Sharding 2020-10-05

      The existing non-deterministic test theoretically should cover all the possible states, but it's tending to mostly cover the node shutting down after the migration has already committed.

      This ticket is to either:

      1) Make the test randomly set one of three failpoints before starting the migration thread:

      • A failpoint to make the migration hang in the dataSync state. This failpoint doesn't exist yet and could be added here.
      • A failpoint to make the migration hang in the blocking state (already exists)
      • A failpoint to make the migration abort (already exists)

      or

      2) Split the test into 4 cases, one for each failpoint (to cover kDataSync, kBlocking, and kAborted) plus one without any failpoints (to cover kCommitted).

            Assignee:
            jason.zhang@mongodb.com Jason Zhang (Inactive)
            Reporter:
            esha.maharishi@mongodb.com Esha Maharishi (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: