Skip to content

fix: close pipe readers before join() to prevent conformance test hang#260

Merged
dfa1 merged 1 commit into
mainfrom
fix-raincloud-pipe-deadlock
Jul 11, 2026
Merged

fix: close pipe readers before join() to prevent conformance test hang#260
dfa1 merged 1 commit into
mainfrom
fix-raincloud-pipe-deadlock

Conversation

@dfa1

@dfa1 dfa1 commented Jul 11, 2026

Copy link
Copy Markdown
Owner

Summary

  • Fixes RaincloudConformanceIntegrationTest: pipe deadlock when a producer outruns an early-exiting comparator #259: RaincloudConformanceIntegrationTest.assertMatchesParquetOracle could hang forever when a producer thread (e.g. CsvExporter) outruns a comparator that stopped reading early (oracle abort, line mismatch). Confirmed via jstack: main thread parked on Thread.join() for 18+ minutes, ~4s CPU time.
  • Close both PipedReaders before calling join() on the producer threads, so a producer blocked on a full pipe buffer gets an IOException instead of blocking forever. The artificial "Pipe closed" error ranks below the real captured errors in the existing priority order, so behavior is unchanged on every other path.

Discovered while triaging #257 — that fix is the first case where the vortex-java CSV export actually succeeds on a repeated/list column and produces enough output to outrun an early-exiting reader (the oracle aborts near-instantly on maxRepetitionLevel > 0 columns).

Test plan

  • ./mvnw verify -pl integration -am -Dit.test=RaincloudConformanceIntegrationTest — passes in ~4s (previously hung)
  • Reproduced the hang pre-fix by temporarily flipping glove-6b-50d to ok in expected-status.csv; confirmed post-fix it now cleanly aborts with TestAbortedException: oracle cannot format repeated list column: vector instead of hanging
  • Checkstyle clean

🤖 Generated with Claude Code

#259)

assertMatchesParquetOracle streams the vortex-java CSV export and the
parquet oracle through a PipedWriter/PipedReader pair on two virtual
threads, compared line-by-line by the main thread. If assertFilesMatch
stops reading early (oracle abort, line mismatch), nobody drains the
pipe anymore — a producer still writing blocks forever once its 128KB
buffer fills, and the unconditional join() right after hangs forever.

Never surfaced before #257 because every prior repeated/list column
consumer failed fast (VortexException thrown immediately). #257 is
the first case where the Java side succeeds and outruns an
early-exiting reader (confirmed via jstack: main thread parked on
Thread.join() for 18+ minutes, ~4s CPU time).

Close both readers before join() so a producer parked on a full
buffer gets an IOException instead of blocking; the artificial
"Pipe closed" error ranks below the real captured errors in the
existing priority order, so behavior is unchanged on every other path.
@dfa1 dfa1 merged commit 0b69fe9 into main Jul 11, 2026
6 checks passed
@dfa1 dfa1 deleted the fix-raincloud-pipe-deadlock branch July 11, 2026 20:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

RaincloudConformanceIntegrationTest: pipe deadlock when a producer outruns an early-exiting comparator

1 participant