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

XMLWordPrintableJSON

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

      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 (Inactive)
            Reporter:
            Esha Maharishi (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: