[platform] "Exit code file empty" fails an attempt whose destination logged "Completed integration"

What

The orchestrator reads the destination's exit-code file immediately after the destination logs Completed integration. When the file is not written yet, the orchestrator throws IllegalStateException: Exit code file empty and fails the attempt, despite having already determined that nothing failed.

Versions

• Platform / container-orchestrator 1.0.0
• destination-bigquery 2.12.4

Logs

22:07:57.816 destination  Teardown task complete, marking sync succeeded.
22:07:57.827 destination  Destination completed successfully and all streams were complete.
22:07:57.827 destination  Flushing output consumer prior to shutdown.
22:07:57.827 destination  Completed integration: airbyte/destination-bigquery.
22:07:59.246 orchestrator readFromDestination: exception caught
             java.lang.IllegalStateException: Exit code file empty.
               at io.airbyte.workers.internal.ContainerIOHandle.getExitCode(ContainerIOHandle.kt:105)
               at io.airbyte.workers.internal.LocalContainerAirbyteDestination.getExitValue(LocalContainerAirbyteDestination.kt:119)
               at io.airbyte.workers.general.BufferedReplicationWorker.readFromDestination(BufferedReplicationWorker.java:480)
22:07:59.247 orchestrator readFromDestination: done. (writeToDestFailed:false, dest.isFinished:true)

The destination wrote all its data and logged success. The orchestrator's own line records writeToDestFailed:false, dest.isFinished:true. It failed the attempt purely because the exit-code file was empty 1.4 seconds after Completed integration.

No OOM, eviction or preemption event exists for that window. Nothing was killed.

Frequency

Exit code file empty hit 657 distinct replication jobs between 2026-08-28 and 2026-09-16 on a single deployment, steady at roughly 90 per day.

Expected

ContainerIOHandle.getExitCode should wait for the exit-code file to be written rather than treat an empty file as fatal, at minimum when the worker has already established that the destination finished and nothing failed.

Why it matters

For a normal sync the spurious retry is harmless, because the retry re-merges idempotently. For a truncate refresh the retry destroys the final table. See the companion issue.

Related, but not the same

• #56456, #76113 — No exit code found / Failed to wait for exit value file, where the destination crashed mid-sync. Closed.
• #5870 — Cannot find pod while trying to retrieve exit code, 2021. Closed.

Here the destination completed successfully, and the error string differs.