Files

T

angelandClaude Sonnet 5 e063fb66d4 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

2026-08-20 00:24:04 -06:00

1.8 KiB

Raw Blame History

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.

1.8 KiB Raw Blame History