Sync action decisions to gatekeepers in batches - #241
Draft
ndisidore wants to merge 1 commit into
Draft
Conversation
|
@ndisidore Bonk workflow failed. Check the logs for details. View workflow run · To retry, trigger Bonk again. |
ndisidore
force-pushed
the
nathan/action-sync-driver
branch
from
August 17, 2026 21:15
ce3a8c8 to
bad2ee2
Compare
This was referenced Aug 18, 2026
ndisidore
force-pushed
the
nathan/action-sync-driver
branch
from
August 18, 2026 17:21
bad2ee2 to
27745a2
Compare
|
APIError: Invalid Anthropic API Key |
2 similar comments
|
APIError: Invalid Anthropic API Key |
|
APIError: Invalid Anthropic API Key |
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.
Stacked on #238. This is the overseer side of the batch contract:
AutoApprovalDrainerevolves in place intoActionSyncDriver(action-sync.ts), and the per-action gatekeeper calls are gone from the overseer.A sync pass snapshots the gatekeeper's records, computes the decision frontier (staged manual approvals, then auto-approval rules walking upward exactly like the old drain, then any vetoes deliverable at that point), makes one
applyActionsThrough(frontier, vetoes)call, and translates the result back: covered records become approved with the right attribution (captured before the RPC, so this stays the single pending→approved chokepoint), astoppedaction stays pending with a display-safefailure, andinvalidatedByVetoentries become rejected withcascadedFrom+ the vetoing user's identity. Passes are single-flight per gatekeeper — two simultaneous approvals coalesce into one call at the higher frontier.For approve/reject semantics: approving stages the frontier and awaits the pass (still throws → toast if its action couldn't be applied), and attribution is bookkept honestly — earlier actions riding along under your approval are audited as resolved by you, auto-extended ones by whoever enabled the rule. Rejecting is decided synchronously and never advances the frontier; the veto is marked with a durable
vetoPendingflag and delivered opportunistically on the next pass, so a reject never blocks on (or races) a gatekeeper RPC.Un-migrated gatekeepers still work: on workerd's method-missing error the driver falls back to legacy per-action calls in batch order, caches the verdict per isolate, and logs a warning — that log going quiet is the signal to delete the fallback.
Driver behavior is pinned in
__tests__/action-sync.test.ts(attribution, manual gates, stopped/retry, veto durability across hibernation, cascades, coalescing, fallback ordering).