Skip to content

Take back the two features that only worked on one machine - #21

Merged
davidmckayv merged 1 commit into
mainfrom
revert/in-process-state
Aug 20, 2026
Merged

Take back the two features that only worked on one machine#21
davidmckayv merged 1 commit into
mainfrom
revert/in-process-state

Conversation

@davidmckayv

Copy link
Copy Markdown
Contributor

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 Map inside 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:

  • A question raised on one process and answered on another is reported as no longer open. That is indistinguishable from an expiry, so nobody investigates.
  • Repetition counts split across processes, so a rule written as repeat.count >= 10 never 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 happen audit filter keeps agent.stream_stalled and loses only the repetition entry.

What goes

The ask policy list and its surface, the approval routes and registry, the repetition context on the policy engine, COMPUTER_REPEAT_WINDOW_MS, and the computer.action_repeated and approval audit kinds. Migration 0001_gigantic_sumo goes with it; it added one column, action_policy.ask. Any database that already applied it keeps a defaulted column nothing reads, and drizzle-kit generate reports no drift.

Still to do

The gateway resolves every action's target from a snapshot cache that is also a Map in 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, lint and typecheck clean. 647 pass, 5 skip, 0 fail. db:generate reports no schema changes.

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
davidmckayv merged commit 06a1a84 into main Aug 20, 2026
3 checks passed
@davidmckayv
davidmckayv deleted the revert/in-process-state branch August 20, 2026 02:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant