amazon: add a Ready() signal for ProcessEvents' LISTEN registration

Tests (and any other caller) previously had no way to know when the
Postgres LISTEN behind the reactive event-processing loop had actually
registered, forcing a guessed sleep before relying on it. Mocks now
exposes Ready() <-chan struct{}, closed once listenForNotifications
successfully issues LISTEN. Purely additive - ProcessEvents' signature
is unchanged.

Updates the integration tests to wait on Ready() instead of a flat
sleep, which also cut TestProcessEvents_ReactsToNotification's runtime
from ~0.25s to ~0.06s with no flakes across repeated runs.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XEDaCB7C2NEBgyvqEtZuxY
This commit is contained in:
2026-08-20 00:35:22 -06:00
co-authored by Claude Sonnet 5
parent 1899d76def
commit 579eae5097
3 changed files with 50 additions and 11 deletions
@@ -0,0 +1,23 @@
# Work Summary — 2026-08-05 19:13
## Task
First of the four `domains/amazon` design insights, addressed one at a time per user request: no "now listening" readiness signal from `(*Mocks).ProcessEvents`.
## Change
`domains/amazon/mock.go`:
- `Mocks` gained `ready chan struct{}` (initialized in `NewMocks`) and a `readyOnce sync.Once` guard.
- New exported method `Ready() <-chan struct{}` - closed once `listenForNotifications` successfully issues `LISTEN` on Postgres, i.e. the moment the reactive path is actually live.
- `listenForNotifications` calls `m.readyOnce.Do(func() { close(m.ready) })` right after the `LISTEN` exec succeeds (and before spawning the `WaitForNotification` goroutine).
- `ProcessEvents(ctx) error`'s signature is unchanged - this is purely additive, so `main.go`'s existing call site needed no changes.
`domains/amazon/mock_test.go`:
- `TestProcessEvents_ReactsToNotification` and `TestProcessEvents_ShutsDownOnContextCancel` now `select` on `m.Ready()` (bounded by a 5s timeout as a safety net) instead of a flat `time.Sleep(200 * time.Millisecond)` / `time.Sleep(50 * time.Millisecond)` before proceeding.
## Verification
- `go build ./...` / `go vet ./...` clean.
- `go test ./domains/amazon/... -v -race`: all 4 pass.
- `TestProcessEvents_ReactsToNotification` dropped from ~0.25s to ~0.06-0.07s per run (no longer paying for an arbitrary sleep) - and 10 consecutive runs (`-count=1` each) were all clean, no flakes.
- `make test`: full suite still green, no regressions.
## Notes
This closes insight #1 from `work-summaries/work-summary-Claude-2026-08-04-2318.md`. The other three (fire-and-forget listener notifications, hardcoded poll interval, LISTEN-connection errors being fatal to the whole app) are still open, to be addressed one at a time per the user's request - not done in this pass.