Files
buzz/crates
Matthew dba97eecd9 fix(db): isolate usage metrics advisory-lock test on scratch DB (#3670)
## What Problem This Solves

`test_usage_metrics_lock_has_single_owner_and_releases_on_drop`
hardcodes the **production** advisory lock key (`0x4255_5A5A_4D45_5452`)
on the shared `TEST_DATABASE_URL`. Postgres advisory locks are
per-database, so any live `buzz-relay` pointed at the same DB holds that
key and the test fails (or races the relay tick). Diagnosis time was
burned during #3268 verification, including near-misses on live dev
relays. Fixes #3619.

## Why This Change Was Made

Preferred fix from the issue: run the test on a private scratch DB via
existing `create_scratch_db` / `drop_scratch_db` (same pattern as
replica-routing fixtures). Keep the production lock key so the test
still documents the real constant, without colliding with a running
relay.

## User Impact

- Local `cargo test -p buzz-db -- --ignored` no longer fails when a dev
relay is running against the shared test DB
- Safer: no temptation to `pg_terminate_backend` a live relay to "fix"
the test

## Evidence

- Code review of fixture isolation
- Pattern matches existing `create_scratch_db` usage in this file
- Test remains `#[ignore = "requires Postgres"]` (same as before)

## Related

- Issue: #3619
- None found among open PRs for this exact fix

Signed-off-by: NanoRisk6 <aidashtherapy@gmail.com>
2026-07-30 17:03:53 -04:00
..
2026-07-27 14:18:24 -04:00