Conversation
Preview:
|
ndisidore
added this pull request to stack #544
September 21, 2026 21:10
Approving and rejecting one action at a time put the decision in three places -- the Activity list, the header popover, and every chat card -- each with its own resolver, its own inline "Always approve" shortcut, and, in chat, an optimistic write that guessed the outcome before the server reported one. That guess is not sound under apply-through: a veto can invalidate a later action, so no client can know what a submission decided. The three surfaces also had no way to express "all of these except that one", which is the thing the backend's applyActionsThrough already accepts. Move the decision to Activity, one Gatekeeper connection at a time. useActionReview owns the drafts for the workspace's lifetime: it freezes each connection's boundary the first time the user looks at a *complete* pending snapshot, so a batch can only ever authorize rows that were on screen, and arrivals after that wait behind an explicit Include rather than joining a request the user already read. Vetoes are browser-local intent -- a checkbox sends no RPC -- and Apply submits the captured (boundary, vetoes) pair once, behind a synchronous per-connection guard so a double click cannot duplicate it. Nothing optimistic is written on either outcome: the action subscription remains the only source of a decision, and a refusal keeps the boundary and every still-pending selection so a stopped action can be vetoed and the batch re-submitted. A replaced stub or workspace bumps a session generation that fences late completions out of the new one. Standing policy stays in the Auto-approval tab, which now also offers kinds that only a pending card advertises -- listPreApprovableActions visits gadget-bound connections alone, so an eligible kind could be unconfigurable -- and refuses to grant a new rule on a connection with staged vetoes or a batch in flight, since that would apply rows the user is still deciding about. Revoking is never blocked. Chat cards and the popover preview navigate to that review, focused on the action's own connection, instead of deciding. The composer stays blocked until the awaited action is authoritatively resolved; opening Activity or ticking Veto does not unblock it. useResolveAction, useAlwaysApproveTag, ResolveButton and AutoApproveConfirmDialog have no callers left and are gone, along with chat's applyOptimisticActionState and the auto-approve reload plumbing; useActionEntries, hook toggles and history are untouched. The backend is untouched too: applyActionsThrough, its stop semantics and its tests already describe this behaviour, and this is the first client to use them.
ndisidore
force-pushed
the
feat/apply-though-ui
branch
from
September 21, 2026 22:48
6e6882d to
738cfe3
Compare
|
@ndisidore Bonk workflow failed. Check the logs for details. View workflow run · To retry, trigger Bonk again. |
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
1 participant
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.
Replaces the singular apply/reject action buttons with the batch application work. Sectioned per-connection since each of these has its own sequential queue (though we could make a unified approval view if you prefer that)