chore: harden automation and upstream verification#5
Merged
Conversation
yaacovcorcos
marked this pull request as ready for review
July 18, 2026 11:55
yaacovcorcos
added a commit
that referenced
this pull request
Jul 26, 2026
…findings Ensure the provider updater child process is only ever spawned against a target that was probed, certified, and re-validated under the settings write lock, closing six concurrency/security windows in the confirmed-update boundary: - #1 Immutable probe/settings snapshot threaded through refresh; a single serialized refresh (refreshSemaphore) captures one snapshot and revalidates confirmed targets at the commit boundary. - #2 updateProvider re-validates the confirmed target and captures the exact updater command into immutable locals while holding withSettingsWriteLock, so a concurrent settings write cannot change what gets spawned between validation and capture. The child is spawned OUTSIDE the lock (spawn + await share one update-timeout budget), so a slow or hung spawner.spawn — whose acquire is uninterruptible — can only stall its own request and can never pin the global settings write lock. - #3 Request-owned update state (per-request owner token); a losing duplicate cannot clobber the in-flight update's running state. - #4 Interruption-safe cleanup lands a terminal failed state and kills the child via a scoped finalizer. - #5 Hot getStatuses/stream reads re-derive only a cheap authority key (revision counters) instead of the full maintenance context, so reads never re-probe CLIs or re-resolve the runtime. - #6 Runtime target identity tracked by a monotonic per-provider revision counter (ProviderRuntimeManager.getRevision), excluded from transient install-progress churn; PROVIDER_KINDS derived from ProviderKind.literals. Adds deterministic regression tests for each finding (no sleeps; barriers via Deferred / TestClock.withLive / scheduler drains), including a mutation- sensitive hot-read guard, a mutation-sensitive guard that the settings write lock is released before the unlocked spawn, a hung-process timeout guard, succeeded/unchanged post-update re-probe guards, and a per-provider revision-isolation test. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or 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
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 changed
--require-reviewed-tipas an honest strict review-closeout mode while retaining--review-checkas a strict compatibility aliasWhy
The previous
--review-checkmode calculated unreviewed commits but did not enforce review currency, while ordinary CI invoked that ambiguous mode. Write-capable and release workflows also used mutable major-version action tags, including a third-party action underpull_request_target.Impact
Product CI remains healthy when upstream publishes new optional input. A disposition-review closeout now has a strict command that fails until
reviewedThroughequals the fetched official tip. Workflow dependencies are immutable at execution time and remain maintainable through Dependabot.Validation
.github/workflows/git diff --check