fix: Add retry on locks #4997
Open
fix: Add retry on locks #4997
+394
−269
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Fabianoshz
force-pushed
the
add-rety-on-locks
branch
2 times, most recently
from
284e6f9
to
d313d5a
Compare
Fabianoshz
force-pushed
the
add-rety-on-locks
branch
2 times, most recently
from
e6d6135
to
6fdaa09
Compare
Fabianoshz
force-pushed
the
add-rety-on-locks
branch
from
6fdaa09
to
f554a9b
Compare
|
After some testing, this is what I'm seeing if I run 2 plan at the same time. This doesn't really fix the issue, but at least reduces the amount of times users have to deal with the error messages. |
Fabianoshz
requested review from
GenPage,
nitrocode and
X-Guardian
and removed request for
a team
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
what
I'm opening this as a draft to receive feedback early, I don't expect this to break anything but I believe it could be hidden behind a flag and with better default values for timeout and retries (maybe exponential retry?).
This adds a retry logic to the lock mechanism to mitigate the issue described in here and also in this ADR.
The locking issue itself is more complex and requires much more work, this is just a small step so users don't have to see the error anymore effectively making the code wait instead of asking the user to retry.
why
Currently the user has to rerun any operations that fail because a certain workspace path is locked, this tries just to automate the process.
tests
Will add if this approach receive support.
references
Did my best to try to understand which issues this would affect.
Relates to #3345
Relates to #2921
Relates to #2882
Relates to #4489
Relates to #305
Relates to #4829
Relates to #1847
Relates to #4566
Closes #1618
Closes #2200
Closes #3785
Closes #4489
Closes #4368