flake: TestStandaloneGatewayServe_ShutdownOrder

[flake-investigator]

CI failure

• CI run: https://github.com/coder/coder/actions/runs/30396610950
• Failed job: https://github.com/coder/coder/actions/runs/30396610950/job/90414344124 (test-go-race-pg)
• Failure date: 2026-07-28 21:36 UTC
• Commit: 1a6a8be96ca51dd61e2bcf68ea5a55acfd8cf773
• Commit author: Jon Ayers
• Run attempt: 1

The failure occurred in the same minute as the Slack alert. All 1,934 lines of the failed job log were available and reviewed. This is an actual test failure on attempt 1, not a matrix cancellation/rerun artifact.

Failure evidence

=== FAIL: enterprise/cli TestStandaloneGatewayServe_ShutdownOrder (10.00s)
    aigatewaystart_internal_test.go:457:
        Error Trace: .../enterprise/cli/aigatewaystart_internal_test.go:457
        Error:      Condition never satisfied
        Test:       TestStandaloneGatewayServe_ShutdownOrder

DONE 28593 tests, 72 skipped, 1 failure in 549.643s
make: *** [Makefile:1540: test-race] Error 1

Line 457 is the readiness wait immediately after starting gateway.serve:

dialCtx := testutil.RequireReceive(testCtx, t, dialCtxCh)
require.Eventually(t, gateway.providersLoaded.Load, testutil.WaitShort, testutil.IntervalFast)
requireListenerReady(t, httpAddress)

The dialer had been invoked, but providersLoaded did not become true within testutil.WaitShort under the race detector, so the test never reached its shutdown-order assertions.

Race, panic, and resource checks

Despite this occurring in test-go-race-pg, the complete log contains no WARNING: DATA RACE or race detected during execution of test output. There is also no panic, OOM, allocation failure, disk/file-descriptor exhaustion, or abnormal process termination. This is a test timeout/assertion failure rather than a detected data race or process crash.

Root-cause assessment

Classification: flaky test — timing-dependent standalone AI Gateway provider initialization under -race.

The test uses the short timeout for an asynchronous sequence: start the gateway, establish the blocking DRPC dialer, run the initial provider reload, and publish providersLoaded. Under race instrumentation and full-suite contention, that initialization did not complete in 10 seconds. The run's non-race gateway tests passed, and the commit under test only changes tailnet connection logging, so there is no evidence of a deterministic product regression from this commit.

Likely fix directions:

• synchronize directly on completion of the initial provider reload instead of polling an atomic with WaitShort;
• use a deterministic fake reloader signal in this test; or
• if the operation legitimately needs more time under -race, use the race-aware test timeout tier.

Duplicate search

Searched open and closed coder/internal issues for:

• TestStandaloneGatewayServe_ShutdownOrder
• StandaloneGatewayServe / ShutdownOrder
• aigatewaystart_internal_test.go
• Condition never satisfied with standalone gateway
• test-go-race-pg with shutdown/order/provider initialization
• data-race, panic, OOM, process-crash, and unknown-failure signatures
• recently closed matching issues from the last 30 days

No matching issue was found. Related but not duplicate: #1624 concerns coderd/aibridged TestReady/FalseBeforeConnection hanging before a dialer signal, whereas this failure is in enterprise/cli after the dialer signal while waiting for initial provider load.

Assignment analysis

Ownership commands/line ranges:

git blame -L 403,492 enterprise/cli/aigatewaystart_internal_test.go
git log --oneline -10 --follow enterprise/cli/aigatewaystart_internal_test.go
git log --oneline -20 -- enterprise/cli

The latest meaningful modifier of this shutdown-order test is 468b1a27 (fix: remove standalone AI Gateway http listener dependency on loading providers) by Paweł Banaszewski. The test originated with ccba3969, co-authored by Danny Kopping. Recent substantive provider-reload/standalone-gateway work in this component also includes affb359d and ce94d42e by Danny.

Paweł is not assignable in coder/internal, so assigning dannykopping as the nearest assignable component/test owner. This is based on code ownership, not the failing run author.

Reproduction

The failure is timing-dependent. Stress the race-instrumented test:

go test -race ./enterprise/cli -run '^TestStandaloneGatewayServe_ShutdownOrder$' -count=100

Running the full test-go-race-pg suite with package/test parallelism may be necessary to reproduce the contention seen in CI.

[linear-code]

ENG-3106