README "Key Design Patterns" says shutdown "flushes all pending batches". Shutdown in internal/routewatch/app.go stops the four handlers, each doing a final write, before it stops the streamer. Updates the streamer queues after that, and those already waiting in the queues (up to 20,000 per handler), still reach HandleMessage but are written only if they fill a whole batch, because the handler's flush goroutine has exited. Streamer.Stop also returns without waiting for the workers to empty the queues, and PeeringHandler.Stop returns without waiting for the final write in processLoop.
Failure scenario: stop the daemon while the feed is flowing. The last seconds of updates are not written; a withdrawal among them leaves its route in the table after the restart.
Severity: low
Definition of done
A test, failing before the fix: updates queued in the streamer when shutdown starts are in the database when it ends.
Shutdown stops the streamer first and waits until its workers have handed every queued update to its handler; then each handler writes what it holds before its Stop returns.
make check passes.
Model: opus-5-5
README "Key Design Patterns" says shutdown "flushes all pending batches". `Shutdown` in `internal/routewatch/app.go` stops the four handlers, each doing a final write, before it stops the streamer. Updates the streamer queues after that, and those already waiting in the queues (up to 20,000 per handler), still reach `HandleMessage` but are written only if they fill a whole batch, because the handler's flush goroutine has exited. `Streamer.Stop` also returns without waiting for the workers to empty the queues, and `PeeringHandler.Stop` returns without waiting for the final write in `processLoop`.
Failure scenario: stop the daemon while the feed is flowing. The last seconds of updates are not written; a withdrawal among them leaves its route in the table after the restart.
Severity: low
## Definition of done
- A test, failing before the fix: updates queued in the streamer when shutdown starts are in the database when it ends.
- Shutdown stops the streamer first and waits until its workers have handed every queued update to its handler; then each handler writes what it holds before its `Stop` returns.
- `make check` passes.
Model: opus-5-5
clawbot
self-assigned this 2026-10-14 14:50:32 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
README "Key Design Patterns" says shutdown "flushes all pending batches".
Shutdownininternal/routewatch/app.gostops the four handlers, each doing a final write, before it stops the streamer. Updates the streamer queues after that, and those already waiting in the queues (up to 20,000 per handler), still reachHandleMessagebut are written only if they fill a whole batch, because the handler's flush goroutine has exited.Streamer.Stopalso returns without waiting for the workers to empty the queues, andPeeringHandler.Stopreturns without waiting for the final write inprocessLoop.Failure scenario: stop the daemon while the feed is flowing. The last seconds of updates are not written; a withdrawal among them leaves its route in the table after the restart.
Severity: low
Definition of done
Stopreturns.make checkpasses.Model: opus-5-5