New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[backend/filestate] Allow preview on locked stack #8642
Conversation
The httpstate backend allows previews to proceed even while an update is in progress. This is potentially problematic as the preview may be relative to a partial state of the stack, but ensures that previews will not be blocked on stacks that have long running updates (for example, to allow for concurrent PR jobs to preview changes). This behaviour has been consistent ~forever for the httpstate backend. In the filestate backend, we recently introduced locking, using a quite different (more coarse-grained) approach. As part of this implementation, preview was added to the list of operations that require an exclusive lock on the stack. For consistency, we should loosen this so that preview behaves the same relative to state locking in the filestate and httpstate backends. In the future, we may well want to tighten this up for both backends, with some additional user controls. Also, when the update plans feature lands shortly, that will provide some additional helpful guarantees that a previous preview was not accidentally relative to a partial state. Fixes #8609.
@@ -456,6 +457,25 @@ func TestLocalStateLocking(t *testing.T) { | |||
} | |||
} | |||
} | |||
|
|||
// Run 10 concurrent previews |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added test coverage here - but this test is skipped currently due to #7269. I verified locally that this test correctly fails before the change and succeeds after the change when un-skipped.
Codecov Report
@@ Coverage Diff @@
## master #8642 +/- ##
==========================================
- Coverage 58.80% 56.39% -2.41%
==========================================
Files 634 540 -94
Lines 97295 91931 -5364
Branches 1383 1383
==========================================
- Hits 57216 51847 -5369
- Misses 36823 36878 +55
+ Partials 3256 3206 -50
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚢
The
httpstate
backend allows previews to proceed even while an update is in progress. This is potentially problematic as the preview may be relative to a partial state of the stack, but ensures that previews will not be blocked on stacks that have long running updates (for example, to allow for concurrent PR jobs to preview changes). This behaviour has been consistent ~forever for thehttpstate
backend.In the
filestate
backend, we recently introduced locking, using a quite different (more coarse-grained) approach. As part of this implementation, preview was added to the list of operations that require an exclusive lock on the stack.For consistency, we should loosen this so that preview behaves the same relative to state locking in the
filestate
andhttpstate
backends.In the future, we may well want to tighten this up for both backends, with some additional user controls. Also, when the update plans feature lands shortly, that will provide some additional helpful guarantees that a previous preview was not accidentally relative to a partial state.
Fixes #8609.