Take back the two features that only worked on one machine - #21
Merged
Conversation
The approval registry from #15 kept its pending questions in a Map in the process, and the repetition detector from #17 kept its counts the same way. Both are correct on a laptop and both stop being correct the moment a deployment runs a second server process, which is the deployment every part of this is aimed at: several processes behind a load balancer, serving a company. The failure mode is the reason to take them back rather than leave them and fix them later. Neither one breaks loudly. A question raised on one process and answered on another is reported as no longer open, which reads exactly like an expiry. Counts split across processes mean a rule written as `repeat.count >= 10` never fires, which reads exactly like a Bot behaving itself. A boundary that silently stops enforcing is worse than one that was never advertised, because the deployment is relying on it. The ask lists, the approval surface, the repetition context and the two audit event kinds go with them. What stays is everything that was already right: the stall watchdog, which tracks streams in the process that holds them and belongs there, and the client-side work from #16 and #19. The rule is now on the pull request template, stated before the work rather than at review. Our own gateway snapshot cache has the same problem and is next.
davidmckayv
requested review from
MikeRyanDev,
guidovizoso and
tylerslaton
as code owners
August 20, 2026 02:17
8 tasks
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 this changes
Reverts #15 (the approval registry) and #17 (the repetition detector), and puts the deployment rule on the pull request template.
Why
Both features keep state that outlives a request in a
Mapinside the server process. That is correct on one machine and wrong the moment a deployment runs a second one, which is the deployment this product is aimed at: several server processes behind a load balancer, serving a whole company, with people bringing their own agents.Neither fails loudly, which is why they are being taken back rather than left in place and fixed later:
no longer open. That is indistinguishable from an expiry, so nobody investigates.repeat.count >= 10never fires. That is indistinguishable from a Bot behaving itself.A boundary that quietly stops enforcing is worse than one that was never advertised, because the deployment is relying on it.
What stays
Everything that was already right. The stall watchdog from #19 tracks open streams in the process that holds them, which is where they belong. The client-side work in #16 and #19 is unaffected. The
Did not happenaudit filter keepsagent.stream_stalledand loses only the repetition entry.What goes
The
askpolicy list and its surface, the approval routes and registry, the repetition context on the policy engine,COMPUTER_REPEAT_WINDOW_MS, and thecomputer.action_repeatedand approval audit kinds. Migration0001_gigantic_sumogoes with it; it added one column,action_policy.ask. Any database that already applied it keeps a defaulted column nothing reads, anddrizzle-kit generatereports no drift.Still to do
The gateway resolves every action's target from a snapshot cache that is also a
Mapin the process. It predates all of this and it is load-bearing for the action boundary, so it is the next thing to move to Postgres.Proof
format:check,lintandtypecheckclean. 647 pass, 5 skip, 0 fail.db:generatereports no schema changes.