Aviad Deri
07/09/2026, 3:54 PMkapa.ai
07/09/2026, 3:55 PMINFO level), not an error. It indicates that a worker thread is waiting for a Unix socket file (/var/run/sockets/airbyte_socket_4.sock) to be created as part of Airbyte's inter-container data channel communication during a replication job.
This is a normal part of the sync startup process ā the source/destination containers communicate via socket files, and this message simply means the worker is waiting for that socket to become available. [Github Issue]
However, if your sync is hanging or failing, here are a few things to check:
1. Too many socket paths (DATA_CHANNEL_SOCKET_PATHS): If you're setting JOB_MAIN_CONTAINER_CPU_LIMIT using millicores (e.g., 4000m), there is a known bug where Airbyte misinterprets the value and creates thousands of socket paths instead of the expected few. This causes containers to crash with exec /usr/bin/sh: argument list too long. The workaround is to use whole CPU units (e.g., 4 instead of 4000m). [Github Issue]
2. Broken pipe on socket: A java.io.IOException: Broken pipe on the source-to-destination socket means the downstream process exited unexpectedly. This is typically a transient error and may resolve on retry. [PR #76895]
Recommended next steps:
⢠Check if the sync eventually succeeds or fails.
⢠Look for Error, Exception, or Fail in the full sync logs for more context.
⢠Verify your JOB_MAIN_CONTAINER_CPU_LIMIT is set using whole units, not millicores. š 0 button š 0 button ā¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Aviad Deri
07/12/2026, 5:59 AMkapa.ai
07/12/2026, 5:59 AMTeardownTask waiting message
This line:
Waiting for TaskWrapper(io.airbyte.cdk.load.task.implementor.TeardownTask@60897453) to complete
is an INFO-level message indicating the sync pipeline is in its final cleanup/teardown phase. This is a normal part of sync completion. In the knowledge sources, similar teardown sequences are seen in successful syncs. [Github Issue]
2. The Datadog warning
WARN com.datadog.profiling.uploader.ProfileUploader - Failed to upload profile to http://localhost:8126/profiling/v1/input java.net.ConnectException: Failed to connect to localhost/127.0.0.1:8126
This is a Datadog Java agent warning ā it means the Datadog profiling agent inside the container cannot reach a local Datadog agent on port 8126. This is not an Airbyte error and does not affect your sync. It is a known benign warning seen in other Airbyte deployments as well. [OOM discussion]
In summary:
⢠Neither of these messages indicates a sync failure on their own.
⢠If your sync is still hanging or failing, look for ERROR, Exception, or OutOfMemoryError entries in the logs for the real root cause.
⢠If the TeardownTask never completes, that would be worth investigating further by checking if the destination connector is stuck. š 0 button š 0 button ā¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Aviad Deri
07/12/2026, 9:17 AMkapa.ai
07/12/2026, 9:17 AMCould not find attempt stats for job_id: 553 and attempt no: 0
means Airbyte's server is querying for sync statistics (records emitted, bytes committed, etc.) for a job attempt, but cannot find them in the database ā specifically in the attempt_sync_stats table that backs the attempts records. [Forum Post] [Forum Post]
This is consistent with the WARN Missing stats for job X attempt Y messages seen in other deployments. [Github Issue]
What this means:
⢠The attempt record exists in the attempts table (job 553, attempt 0), but no corresponding stats row was written for it.
⢠This typically happens when a sync attempt starts but the replication worker never successfully writes stats back to the database ā often because the job was cancelled, timed out, or the worker pod was killed before stats could be persisted.
What to check:
1. Did the sync actually complete? Check the job status in the Airbyte UI for job 553. If it shows as cancelled or failed, the missing stats are expected.
2. Is the sync hanging? Based on your earlier logs (TeardownTask waiting, socket waiting), the worker may be getting stuck before it can write stats.
3. Check worker pod logs for the replication pod associated with job 553 for any OOM kills, crashes, or timeout errors.
4. This is generally not the root cause ā it is a symptom. The underlying issue is likely why the worker is not completing normally.
The knowledge sources do not provide a definitive fix for this specific error, so I'd recommend opening a support ticket or GitHub issue with your full worker logs if the syncs are consistently failing. š 0 button š 0 button ā¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.