Flaky: TestCheckDockerAvailability_UsesShellwrapResolver times out at its 2s budget under load

[Dumbris]

Summary

TestCheckDockerAvailability_UsesShellwrapResolver (internal/upstream) fails at exactly 2.00s when the package runs under load, and passes in ~0.37s in isolation. It sits on a 2-second context.WithTimeout Docker-availability probe while the package's own total runtime is ~1.9–2.0s, so on a busy machine the probe simply runs out of budget.

Sibling of #1150, different mechanism: #1150 was a genuinely wrong assertion; this one is a correct assertion with no headroom.

Evidence

Same worktree, same commit (0909c4d88, main), Docker daemon up throughout:

# full package, machine loaded (parallel agent workflow running)
--- FAIL: TestCheckDockerAvailability_UsesShellwrapResolver (2.00s)
FAIL    github.com/smart-mcp-proxy/mcpproxy-go/internal/upstream   4.080s

# the same test alone, x3
ok      github.com/smart-mcp-proxy/mcpproxy-go/internal/upstream   0.373s
ok      github.com/smart-mcp-proxy/mcpproxy-go/internal/upstream   0.368s
ok      github.com/smart-mcp-proxy/mcpproxy-go/internal/upstream   0.373s

# full package again, machine quieter, x3
ok      github.com/smart-mcp-proxy/mcpproxy-go/internal/upstream   1.981s
ok      github.com/smart-mcp-proxy/mcpproxy-go/internal/upstream   2.010s
ok      github.com/smart-mcp-proxy/mcpproxy-go/internal/upstream   1.914s

The (2.00s) duration is the tell — it is the timeout firing, not an assertion failing.

Package runtime pre-dates today's merges (4e91517da: 2.088s / 1.931s), so this is not a regression from a recent change; it has been marginal for a while and only shows under contention.

Why it is worth fixing

I hit this three times in one session and misattributed it twice — first to my own teardown of some test containers, then to that day's merges. A test that fails only under load, with a duration that looks like a hang, is one a reader will blame on their environment or on whatever they just changed. That is the same tax #1150 was charging.

Suggested fix

Don't just raise the constant — that keeps the same shape with a bigger number. Either:

• inject the probe deadline so the test controls it rather than sharing a production-shaped 2s budget, or
• make the availability check's result injectable so the test does not perform a real Docker probe at all (it is asserting which resolver is used, not that Docker answers within 2s).

The second matches what the test's name says it is checking.

[Dumbris]

Second test with the same shape: TestMaskTextStaysCheapOnAPayloadFullOfSecrets (internal/security)

Same failure mode as the one this issue names, so recording it here rather than opening a third.

# inside a full 'go test ./internal/... -race' run, machine loaded
--- FAIL: TestMaskTextStaysCheapOnAPayloadFullOfSecrets (2.05s)
FAIL    github.com/smart-mcp-proxy/mcpproxy-go/internal/security   15.755s

# the same test alone, x3
ok      github.com/smart-mcp-proxy/mcpproxy-go/internal/security   0.408s
ok      github.com/smart-mcp-proxy/mcpproxy-go/internal/security   0.195s
ok      github.com/smart-mcp-proxy/mcpproxy-go/internal/security   0.303s

# the whole package alone
ok      github.com/smart-mcp-proxy/mcpproxy-go/internal/security   0.519s

A ~0.2s operation failing a budget at 2.05s is a factor of ten, so this is contention (the race detector, plus parallel packages, plus other load) rather than a slow path.

I hit this twice today on branches that do not touch internal/security, and both times my first instinct was to suspect the change in front of me. That is the actual cost: a wall-clock budget with no headroom turns every unrelated diff into a suspect.

Both this and TestCheckDockerAvailability_UsesShellwrapResolver assert something real — one that masking is cheap, one which resolver is used — but they assert it through elapsed time on a shared machine. The durable fix is the same for both: assert the property directly (an operation/allocation count, or an injected resolver and deadline) instead of through wall-clock. Raising the constant only moves the threshold.