Check for LEADING *after* waiting to be LEADING or FOLLOWING #1873
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Details
This fixes a bug noticed when investigating a fork.
If we attempt to start a command, but are not LEADING or FOLLOWING (see lines 783-796, the collapsed section between the changes) we wait until we are before doing anything.
However, we've performed the
canWriteParallel
before we wait for this state change, so we could have been SEARCHING before the wait, and LEADING after. This will causecanWriteParallel
to befalse
when it should not be. This leads to commands running in the sync thread that do not need to.This change moves the check for
LEADING
to after the state of the server has stabilized.I don't believe this actually affects the fork that occurred, but it is a detriment to performance.
Fixed Issues
Fixes https://github.com/Expensify/Expensify/issues/384477
Tests
Internal Testing Reminder: when changing bedrock, please compile auth against your new changes