mirror of
https://github.com/block/buzz.git
synced 2026-10-30 14:01:37 +00:00
6d719c680a
## Summary At boot the relay's read pool holds only its floor (`max/5`). A freshly started pod that meets a reconnect burst, such as the clients a rolling deploy just moved off an old pod, has to dial the rest of its reader connections inside the 150ms reader acquire budget. Cold dials (TCP + TLS + SCRAM) overrun that budget under load, so those reads fall back to the writer (`reader_acquire_timeout`). This PR warms the read pool toward its ceiling in the background, right after the existing boot ping succeeds: - **Off the startup path.** It runs in the boot-ping task that was already spawned and not awaited. Startup and readiness are unchanged. - **Bounded.** One pass, in waves of at most 5 concurrent dials. Each acquire, dial included, is bounded by the pool's own 150ms acquire timeout. A dial slower than that is dropped and counts as failed, just as it would on the request path. A wave that opens nothing ends the pass, and the pass runs at most twice the waves a clean pass needs. There is no sleep, backoff or second pass. - **Released idle, then reaped.** Warmed connections are dropped back into the pool, not closed. sqlx's existing `idle_timeout` reaps them back down to the floor, so there is no new reaping logic. - **Skipped if the reader is down.** If the boot ping finds the reader unreachable, the warm pass doesn't run. Today's all-writer warning is the only signal in that case. - **No alert noise.** Warm acquires use plain `acquire()`, not the instrumented reader acquire, so warm misses don't count toward the `buzz_db_reader_*` acquire-timeout metrics that fallback alerts watch. The existing `buzz_db_read_pool_*` gauges show the result. - **Logged.** The outcome is logged at info when the pool reaches its ceiling, and at warn when it falls short. Both lines carry `ceiling`, `held`, `failed` and `elapsed_ms`. The ceiling field isn't named `target`, because the relay's JSON formatter already emits the event target under that key. `held` counts the connections the pass dialed plus any idle floor connections it reused. - **Window.** Until the pass ends it holds every reader connection, the floor included. That is usually before the pod takes traffic. Boot-probe retries can delay the pass past the listener bind, though, so it can briefly overlap traffic, and a routed read that misses in that window falls back to the writer. **Cost.** Each pod holds up to `max_connections` reader connections, instead of the floor, for about `idle_timeout` after boot. Operators should size the reader's `max_connections` for pods × `BUZZ_DB_READ_POOL_SIZE` (falling back to `BUZZ_DB_POOL_SIZE`), counting the old and new pods that overlap during a rolling deploy. The configuration already permits that, and the `reader_min_connections` doc now gives the same advice. Booting pods can have up to the floor plus 5 dials in flight, because sqlx's floor maintenance dials alongside the first warm wave. **Simpler?** This adds one bounded helper and leaves the pool configuration alone: no new knob and no new metric. Separately, I identified some debt: a REQ with `limit: 0` still acquires a reader to run an empty query. A short-circuit straight to EOSE would remove that acquire, and a companion desktop change sends `limit: 0` live REQs. ### Related issue N/A. This is part of a set of reconnect-load reductions. The companion client changes (resume cursor, reconnect spreading) are in separate PRs. ### Testing - `cargo fmt --all -- --check`, plus `cargo clippy -p buzz-db -p buzz-relay --all-targets -- -D warnings`. - `cargo test -p buzz-db`, including 6 new `reader_warm_tests`: - a table test for wave sizing - an exact target - the bound when dials keep missing - a top-up after a partial wave - a dead reader ending the pass after one wave - an unreachable reader skipping the warm - The new Postgres test `reader_pool_postgres_tests::reader_boot_ping_warms_pool_to_max_in_background`: after `spawn_read_pool_boot_ping()`, the pool settles at size = idle = max. It runs through `scripts/postgres-test-run.sh` together with the existing reader-pool Postgres tests, and `scripts/test-postgres-test-discovery.sh` passes. - The new Postgres test `reader_pool_postgres_tests::reader_warm_at_production_budget_ends_partial_when_dials_stall`. It builds the pool with the production constructor, so it has the real 150ms budget, and puts it behind a proxy that relays 3 dials and stalls the rest mid-handshake. The pass must end with 3 held and 7 failed after exactly 10 dials, finish in under 2s, and not dial again afterward. - Mutation checks. Each of these failed a new test: - zero waves - targeting the floor instead of the ceiling - `close_on_drop` instead of releasing - no early abort - no wave bound - no top-up - no ping gate - no concurrency cap buzz-review-completed 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: Luke Tornquist <tornquist@squareup.com> Co-authored-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>