Summary
The full swift test -c release run hangs partway through — the test process sits at 0% CPU with no further output indefinitely. It does not complete.
Observations
- Reproduces under both
swift test (parallel) and swift test --no-parallel (serialized).
- Serialized, the run wedges in
FileOperationsServiceTests (Tests/DICOMStudioTests/FileOperationsTests.swift): test_service_initialState_idleNoFiles passes, then the next test in the suite never completes.
- Parallel, the last flushed output is in the JP3D area — but parallel ordering is unreliable, so the serialized wedge point is the authoritative one.
- ~3000 tests pass before the wedge. Memory is fine (~76% free, test process RSS ~1.4 GB) — not memory exhaustion. No zombie/leaked processes.
Not a J2K / codec problem
Every J2K-related suite passes standalone:
J2KSwiftCodecTests, HTJ2KTests, HTJ2KOpenJPHComparisonTests, J2KSwiftCodecBenchmarkTests, J2KvsHTJ2KCompressionReportTests, JP3DCodecTests, KakaduJ2KSwiftSampleStudiesTests, DICOMStudioPanelSubstituteTests.
Surfaced during the J2KSwift v10.9.3 bump, but the codec surface is unaffected — this is a DICOMStudio test-infrastructure issue.
Not yet isolated
Isolated runs of FileOperationsServiceTests could not be cleanly reproduced — filtered runs produced empty output and had to be killed, possibly an output-capture interaction. A full earlier run on J2KSwift v10.9.1 did complete green this session, so something shifted; the cause is still open.
Suggested investigation
- Run
FileOperationsServiceTests in isolation on a fresh environment (reboot — the machine had hours of build/test cycles + repeated process kills when this was found).
- Inspect
FileOperationsService for an async path that can deadlock — a @MainActor hop, a directory watcher / DispatchSource, or a sync-over-async bridge — particularly anything reachable from test_service_setDropMode_changesModeAndClearsFiles onward.
- Consider whether DICOMKit's
J2KSwiftCodec.awaitJ2KResult sync-over-async bridge (DispatchSemaphore + Task.detached) contributes under full-suite load — it blocks a thread the awaited Task may need.
🤖 Filed with Claude Code
Summary
The full
swift test -c releaserun hangs partway through — the test process sits at 0% CPU with no further output indefinitely. It does not complete.Observations
swift test(parallel) andswift test --no-parallel(serialized).FileOperationsServiceTests(Tests/DICOMStudioTests/FileOperationsTests.swift):test_service_initialState_idleNoFilespasses, then the next test in the suite never completes.Not a J2K / codec problem
Every J2K-related suite passes standalone:
J2KSwiftCodecTests,HTJ2KTests,HTJ2KOpenJPHComparisonTests,J2KSwiftCodecBenchmarkTests,J2KvsHTJ2KCompressionReportTests,JP3DCodecTests,KakaduJ2KSwiftSampleStudiesTests,DICOMStudioPanelSubstituteTests.Surfaced during the J2KSwift v10.9.3 bump, but the codec surface is unaffected — this is a DICOMStudio test-infrastructure issue.
Not yet isolated
Isolated runs of
FileOperationsServiceTestscould not be cleanly reproduced — filtered runs produced empty output and had to be killed, possibly an output-capture interaction. A full earlier run on J2KSwift v10.9.1 did complete green this session, so something shifted; the cause is still open.Suggested investigation
FileOperationsServiceTestsin isolation on a fresh environment (reboot — the machine had hours of build/test cycles + repeated process kills when this was found).FileOperationsServicefor an async path that can deadlock — a@MainActorhop, a directory watcher /DispatchSource, or a sync-over-async bridge — particularly anything reachable fromtest_service_setDropMode_changesModeAndClearsFilesonward.J2KSwiftCodec.awaitJ2KResultsync-over-async bridge (DispatchSemaphore+Task.detached) contributes under full-suite load — it blocks a thread the awaitedTaskmay need.🤖 Filed with Claude Code