Test parallelism conflict

What this failure means

Parallel test execution caused a resource conflict: two tests tried to bind the same port, access the same fixture, or write to the same temporary file simultaneously.

Symptoms

Faultline looks for one or more of these log fragments:

resource is busy
test is not parallelizable
concurrently
race detected
too many connections
database locked
concurrent =
re:\bconcurrent access\b

Diagnosis

Parallel test execution caused a resource conflict: two tests tried to bind the same port, access the same fixture, or write to the same temporary file simultaneously.

Fix steps

1. Reduce test parallelism with -parallel 1 to confirm the conflict is parallelism-related.
2. Allocate a unique port, database, or temp directory per test rather than sharing a fixed resource.
3. Use test-specific prefixes or random ports in each test’s setup.
4. If the suite must share a resource, serialize only the affected tests instead of disabling parallelism globally.

Validation

• Re-run the failing workflow step.
• Confirm the original failure signature for Test parallelism conflict is gone.

Why it matters

Tests that were written to run sequentially are now running in parallel due to an increased -parallel value or a new CI matrix. Without resource isolation, they interfere with each other.

Prevention

• Design each test to be fully isolated and self-contained.
• Avoid hardcoded ports or global singletons in test setup.
• Run the full test suite in parallel locally before enabling parallel CI.
• Provide shared helpers for ephemeral ports, temp databases, and per-test workspaces so resource isolation is the default.

Try it locally

go test -parallel 1 ./...
go test -parallel 1 ./...

How Faultline detects it

Use faultline explain parallelism-conflict to see the full playbook.

faultline analyze build.log
faultline explain parallelism-conflict

Generated from playbooks/bundled/log/test/parallelism-conflict.yaml. Do not edit directly.