Repository navigation
test: stop integration suites failing on container teardown timeout - #466
Merged
Merged
Conversation
Recent CI failures on green code (MariaDB twice, postgres-ssh once) all read "Hook timed out in 10000ms" at the suite's afterAll. Teardown is Testcontainers' stop(), i.e. `docker stop -t 0` + `docker rm -v`. The suites share one Docker daemon, and while Oracle (1.2GB) or SQL Server is still pulling/extracting its image, removing a sibling container with its data volume can exceed Vitest's default 10s hookTimeout. Every beforeAll already carries an explicit 60-360s timeout; afterAll relied on the default. - vitest.config.ts: hookTimeout 60s for the integration project. - IntegrationTestBase.cleanup(): stop the container in a finally so a disconnect failure can't leak a running container. - testing skill: document the symptom and cause. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TZPfFnRTrHzHhsCzjrZjgM
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The functional changes are focused and correct; only a minor overstatement in a code comment remains.
1 open finding
What changed in this PR
Improves integration-test teardown reliability under Docker contention.
Changes:
- Raises integration hook timeout to 60 seconds.
- Ensures containers stop after disconnect failures.
- Documents teardown timeout troubleshooting.
| File | Description |
|---|---|
vitest.config.ts |
Configures integration hook timeout. |
src/connectors/__tests__/shared/integration-test-base.ts |
Makes container cleanup resilient to disconnect failures. |
.claude/skills/testing/SKILL.md |
Documents the CI failure mode and convention. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
A pending disconnect() never reaches the finally, so the container-stop guarantee covers thrown errors, not hangs; say so. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TZPfFnRTrHzHhsCzjrZjgM
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Problem
Integration CI fails intermittently on green code. Pulling the failed-job logs for every red
Run Testsrun over the last two months, the flaky failures are all the same line:Seen on MariaDB twice (2026-10-09, runs 37904209709 and 37896731506) and on postgres-ssh once (2026-09-28, run 36420437936). In each case every test passed and only the suite's
afterAlltimed out. The other red runs in that window were genuine failures on WIP branches, not flakes.Root cause
Teardown is Testcontainers'
stop(), which runsdocker stop -t 0followed bydocker rm -v(removing the container's anonymous data volume). All integration suites run in parallel against one Docker daemon. While Oracle (1.2GB image) or SQL Server is still pulling/extracting, removing a sibling container plus its volume can exceed Vitest's default 10shookTimeout.Every
beforeAllin these suites already carries an explicit 60–360s timeout; everyafterAllrelied on the default. The postgres-ssh case confirms it is the container stop and not the connector: that suite'safterAllonly callscontainer.stop().Changes
vitest.config.ts:hookTimeout: 60_000for the integration project, with a comment explaining why. Setup hooks keep their explicit per-suite timeouts.IntegrationTestBase.cleanup(): stop the container in afinallyso a faileddisconnect()can't leak a running container into the next suite..claude/skills/testing/SKILL.md: troubleshooting entry for the symptom and cause.Verification
tsc --noEmitpasses.pnpm test:unit: 1201 tests pass.Not done on purpose: limiting integration file concurrency would also reduce the contention but slows CI noticeably; the timeout fix addresses the failure directly.
🤖 Generated with Claude Code
https://claude.ai/code/session_01TZPfFnRTrHzHhsCzjrZjgM
Generated by Claude Code