flake: TestPrebuildsAutobuild/DefaultTTLOnlyTriggersAfterClaim

[flake-investigator]

CI Run: https://github.com/coder/coder/actions/runs/27370305360
Job: https://github.com/coder/coder/actions/runs/27370305360/job/80880576441 (test-go-race-pg)
Commit: 112c9212353e7a7a5a4c1aab02c985b91c036ce4 (Zach / zedkipp) coder/coder@112c921

Failure:

=== FAIL: enterprise/coderd TestPrebuildsAutobuild/DefaultTTLOnlyTriggersAfterClaim (32.29s)
workspaces_test.go:1951: found 0 running prebuilds so far, want 1

(The log shows repeated found 0 running prebuilds so far, want 1 before the test fails.)

Error analysis:

• TestPrebuildsAutobuild/DefaultTTLOnlyTriggersAfterClaim waits for a running prebuild via getRunningPrebuilds + testutil.Eventually but never observes the expected prebuild instance in this run.
• Looks like a timing/backpressure flake in the prebuild reconciler path; the prebuild does not reach running before the test deadline.

Root cause classification:

• Flaky test (timing / prebuild reconciliation delay).

Data race / panic / OOM checks:

• No WARNING: DATA RACE, panic, or OOM indicators found in the job logs around this test.

Assignment analysis:

• Failing test location: enterprise/coderd/workspaces_test.go (DefaultTTLOnlyTriggersAfterClaim, around lines ~2013+)
• Intended blame command:
  • git blame -L 2013,2145 enterprise/coderd/workspaces_test.go
• Tooling limitation: line-level blame isn’t available here, so I used recent file history instead.
  • git log --oneline -10 --follow enterprise/coderd/workspaces_test.go -> most recent change 4e2c9f9 (Callum Styan / @cstyan)
• Assigning to @cstyan as the most recent meaningful modifier of this test file. Please reassign if ownership differs.

Related issues searched (coder/internal, open/closed):

• "TestPrebuildsAutobuild"
• "DefaultTTLOnlyTriggersAfterClaim"
• "workspaces_test.go"
  No duplicates found.

Reproduction (best effort):

go test ./enterprise/coderd -run TestPrebuildsAutobuild/DefaultTTLOnlyTriggersAfterClaim -count=1

[linear-code]

ENG-2862

[cstyan]

Hey @Emyrk it looks like this is actually not just the TestPrebuildsAutobuild/DefaultTTLOnlyTriggersAfterClaim test that's failing but a whole bunch of tests all failing due to a data race. IIUC, based on what I'm understanding from investigating with some AI help, is that these are likely failures due to usage of ReloadBuiltinRoles. It looks like this can result in rewriting of the underlying map used here while other routines are reading/writing to it.

I see that you have a TODO about a refactor here but I don't really have enough context to tackle that right now and deal with any fall out of the refactor. Would storing the map as an atomic.Pointer be a valid band aid in the mean time?

[Emyrk]

@cstyan I will look today