Hi @kapa.ai for one of my custom python connectors. the sync fails (i can see from the logs & also attempts table in db with its output col) but doesn't mark it as failed. Silently failing is even a bigger problem because it goes undetected and can easily be missed.

You’re right to be concerned: “silent” failures are a known class of issues in Airbyte, especially with custom or some destination connectors. From the knowledge sources, there are several similar reports: • MSSQL destination: tables created but no data written and sync marked successful, clearly identified as a bug in the connector’s error handling. [MSSQL silent] • MySQL source: sync finishes as

successful

but no data is synced, and neither success nor failure notifications are triggered. [MySQL success] • S3 Datalake: failures on large syncs are marked as success, with data only on a staging branch; user explicitly calls out the risk of “silent failure.” [S3 silent] These show that Airbyte can mark jobs as successful even when the connector has effectively failed, usually because: • The connector process exits with code

0

and does not emit an explicit error or failure signal. • Errors are swallowed or logged but not propagated as failing messages / non‑zero exit codes. For your custom Python connector, the knowledge sources do not provide specific implementation guidance for fixing this in code, so I can’t give you connector-side code examples. The sources only show that: • When a sync truly fails at the platform level, Airbyte will mark it as failed and retry up to 3 times. [What happens if a sync fails?] • When a connector mishandles errors (e.g., ignores HTTP 400s or write failures), the platform may think the job succeeded. This was explicitly fixed for PayPal by changing from “silently ignoring errors” to “failing with an error status.” [PayPal 400 fix] Given that, the most likely cause in your case is: > Your custom connector is logging the error but still exiting “cleanly” (exit code 0 / no failing message), so the Airbyte platform marks the attempt as succeeded even though your own logs and the

attempts

table show a failure condition. Because the knowledge sources don’t include the Python CDK or connector implementation details, I can’t point you to exact methods or patterns to change in your code. I can only suggest, at a high level: • Ensure that when your connector detects a fatal error, it: ◦ Does not swallow it silently, and ◦ Causes the process to exit with a non‑zero exit code or otherwise emit a failure that the platform can interpret as an error (similar to how the PayPal connector was changed to “fail with an error status” instead of ignoring the error). [PayPal 400 fix] • Collect and share full job logs (with secrets redacted) if you open a GitHub issue, as was requested for other silent‑failure bugs (MSSQL, S3 Datalake). [MSSQL silent; S3 silent] If you want this investigated as a potential platform/connector bug (rather than only a connector‑code issue), the pattern from the issues above is: 1. Go to your connection → Job history → pick a problematic sync → download logs. [MSSQL silent] 2. Open a GitHub issue against Airbyte with: ◦ Airbyte version ◦ How you deploy (OSS / Cloud, K8s / Docker, etc.) ◦ Connector type (custom Python source/destination) ◦ The job logs (redacted) ◦ Evidence from the

attempts

table that the connector “failed” logically while the job is marked successful. Because the sources don’t contain more detailed guidance for custom Python connectors, I can’t be more specific without going beyond the provided information. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai at the end these are the logs 2026-02-25 052208 replication-orchestrator ERROR DestinationReader error: 2026-02-25 052208 replication-orchestrator INFO DestinationReader finished. 2026-02-25 052208 replication-orchestrator ERROR DestinationWriter error: 2026-02-25 052208 replication-orchestrator ERROR DestinationWriter error: 2026-02-25 052208 replication-orchestrator INFO MessageProcessor finished. 2026-02-25 052208 replication-orchestrator WARN Attempted to close a destination which is already closed. 2026-02-25 052208 replication-orchestrator INFO DestinationWriter finished. 2026-02-25 052209 replication-orchestrator ERROR SourceReader error: 2026-02-25 052209 replication-orchestrator INFO SourceReader finished. 2026-02-25 052209 replication-orchestrator ERROR runJobs failed; recording failure but continuing to finish.

I’m missing the actual log snippet you’re referring to—nothing was included after “at the end these are the logs”. The knowledge sources do show several similar “silent failure” patterns (job marked success while logs clearly show errors), but they don’t contain your specific connector’s logs, so I can’t interpret your case precisely. [S3 silent; MySQL success] To move forward based on what is documented: 1. Confirm platform vs. connector view of status ◦ In other issues, the internal job summary clearly shows

"status": "failed"

while the UI/API shows success. [S3 silent; Pod success bug] ◦ Check your job’s summary section in the logs and the

attempts

table to see if they say

failed

even though the UI says

succeeded

. 2. Check if your connector exits “cleanly” ◦ Similar bugs happened when connectors logged errors but did not cause the process to fail, so Airbyte treated the job as successful. [MSSQL silent; Partner error handling] ◦ For a custom connector, you need to ensure that on a fatal error it does not just log and continue, but actually terminates in a way the platform sees as a failure (non‑zero exit / proper error trace). The docs explicitly say “silent errors are not permitted.” [Partner error handling] 3. If this looks like a platform bug ◦ There is an open issue where the workload is internally marked FAILED but the UI/public API still show success. [Pod success bug] ◦ For that, maintainers requested: platform version, deployment type, and full job logs to reproduce. [Pod success bug] If you paste the relevant tail of your logs (redacting sensitive info), I can try to map it to one of these known patterns and suggest whether it’s more likely a connector‑side error‑handling issue or the same status‑propagation bug described above. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai this is the internal message i see in attempts table Airbyte could not track the sync progress. Sync process exited without reporting status.

The message you see in the

attempts

table: >

Airbyte could not track the sync progress. Sync process exited without reporting status.

matches a known class of errors in Airbyte where the workload (sync process) dies without sending its final status back to the platform. This exact wording appears in other issues: • As a warning from the source/destination: > “Workload failed, source: workload-monitor-heartbeat: Airbyte could not track the sync progress. Sync process exited without reporting status.” [All sync jobs hanging] • As a

WorkloadMonitorException

in Airbyte Cloud: >

message='Airbyte could not track the sync progress. Sync process exited without reporting status.'

[Amazon Seller Partner] In those cases: • The platform knows something went wrong (the process exited unexpectedly / without reporting status). • The sync is treated as a failure internally (jobs fail or get stuck, retries happen, etc.). [All sync jobs hanging; Amazon Seller Partner] Separately, there is an open bug where a workload is marked FAILED internally but the UI/public API still report the sync as successful (status propagation bug). [Replication pod success bug] There is also an S3 Datalake issue where the sync summary shows

"status": "failed"

but the user reports failures being effectively treated as success. [S3 Datalake] Putting this together for your case: • Your logs show

runJobs failed; recording failure but continuing to finish.

plus

DestinationReader error

,

DestinationWriter error

,

SourceReader error

— this matches other failed syncs. [S3 Datalake; Firestore] • Your

attempts

table has the internal message

Airbyte could not track the sync progress...

, which is exactly how Airbyte records these “workload died without reporting status” failures. [All sync jobs hanging; Amazon Seller Partner] • Yet you’re observing that the sync is not marked as failed (i.e., it’s effectively a “silent” failure). The knowledge sources strongly suggest this is the same class of problem as: • The status propagation bug where a FAILED workload is not surfaced correctly to the UI/API. [Replication pod success bug] • The S3 Datalake “Failures marked as success” issue. [S3 Datalake] They do not provide a concrete fix for your specific custom Python connector or a step‑by‑step workaround, so there is some unavoidable uncertainty. Based on what is documented, the recommended next steps are: 1. Confirm the sync summary in the logs Look for a

Sync summary: { "status" : "failed", ... }

block in the same job logs. This is how similar failures are recorded. [S3 Datalake; Firestore] 2. Treat this as a platform/status bug and open an issue Since the

attempts

table and logs clearly indicate a failure, but the job is not marked failed, this aligns with the existing “failed internally but reported as success” bug. [Replication pod success bug] In your GitHub issue, include: ◦ Airbyte version and deployment (OSS/Cloud, Docker/K8s, etc.). ◦ Connector details (custom Python source/destination). ◦ The log tail you shared plus the sync summary. ◦ The

attempts

table row showing the internal message. 3. Connector‑side: ensure hard failure on fatal errors Airbyte’s destination requirements explicitly say *silent errors are not permitted*; if a destination cannot log errors via the approved protocol, it must fail and raise the error. [Partner error handling] For your custom connector, double‑check that on fatal errors it does not just log and exit “cleanly”, but actually terminates in a way that the platform can reliably treat as a failure. Beyond this, the knowledge sources don’t contain enough detail to say exactly why your run is not marked failed, only that your symptoms match known, open issues around “Airbyte could not track the sync progress” and mis‑reported failure status. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai this is what i see in logs 2026-02-25 052209 replication-orchestrator INFO Failures: [ { "failureOrigin" : "destination", "internalMessage" : "Destination process exited with non-zero exit code 143", "externalMessage" : "Something went wrong within the destination connector", "metadata" : { "attemptNumber" : 0, "jobId" : 73856, "connector_command" : "write" }, "stacktrace" : "io.airbyte.workers.internal.exception.DestinationException: Destination process exited with non-zero exit code 143\n\tat io.airbyte.container.orchestrator.worker.DestinationReader.run(ReplicationTask.kt:54)\n\tat io.airbyte.container.orchestrator.worker.ReplicationWorker$runJobs$2$tasks$1$1.invokeSuspend(ReplicationWorker.kt:151)\n\tat io.airbyte.container.orchestrator.worker.ReplicationWorker$runJobs$2$tasks$1$1.invoke(ReplicationWorker.kt)\n\tat io.airbyte.container.orchestrator.worker.ReplicationWorker$runJobs$2$tasks$1$1.invoke(ReplicationWorker.kt)\n\tat io.airbyte.container.orchestrator.worker.util.AsyncUtils$runAsync$1$1.invokeSuspend(AsyncUtils.kt:22)\n\tat io.airbyte.container.orchestrator.worker.util.AsyncUtils$runAsync$1$1.invoke(AsyncUtils.kt)\n\tat io.airbyte.container.orchestrator.worker.util.AsyncUtils$runAsync$1$1.invoke(AsyncUtils.kt)\n\tat kotlinx.coroutines.intrinsics.UndispatchedKt.startUndspatched(Undispatched.kt:66)\n\tat kotlinx.coroutines.intrinsics.UndispatchedKt.startUndispatchedOrReturn(Undispatched.kt:43)\n\tat kotlinx.coroutines.BuildersKt__Builders_commonKt.withContext(Builders.common.kt:165)\n\tat kotlinx.coroutines.BuildersKt.withContext(Unknown Source)\n\tat io.airbyte.container.orchestrator.worker.util.AsyncUtils$runAsync$1.invokeSuspend(AsyncUtils.kt:21)\n\tat kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)\n\tat kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:100)\n\tat java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)\n\tat java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)\n\tat java.base/java.lang.Thread.run(Thread.java:1583)\n", "timestamp" : 1771977129445 } ]

Your logs and internal message show that Airbyte is correctly detecting a destination failure, but in your case it’s not being surfaced as a failed sync, which matches patterns seen in other issues. From your log:

"failureOrigin" : "destination",
"internalMessage" : "Destination process exited with non-zero exit code 143",
"externalMessage" : "Something went wrong within the destination connector",
...
"stacktrace" : "io.airbyte.workers.internal.exception.DestinationException: Destination process exited with non-zero exit code 143
    at io.airbyte.container.orchestrator.worker.DestinationReader.run(ReplicationTask.kt:54)
    ...

This is the same failure shape as other destination errors: •

Destination process exited with non-zero exit code 1

is a common pattern when the destination crashes; it’s wrapped as a

DestinationException

and recorded with

failureOrigin = "destination"

. [BigQuery exit 1; Zendesk dest error; Replication-orchestrator error] • In your case the exit code is 143, which typically means the container was terminated by a signal (e.g., OOM kill or external stop), but the knowledge sources don’t go into detail on exit code semantics. What we can say from the sources: 1. The platform is treating this as a destination failure The

Failures: [...]

block with

failureOrigin: "destination"

and a

DestinationException

stack trace is exactly how Airbyte records a failed destination process. [Replication-orchestrator error; BigQuery exit 1] 2. This should cause the attempt to be marked failed In similar logs, the attempt is recorded as failed with the same internal message “Destination process exited with non-zero exit code 1” and surfaced as a destination failure. [BigQuery exit 1; BigQuery project-id bug] 3. But you’re seeing “Airbyte could not track the sync progress. Sync process exited without reporting status.” in the attempts table and the sync is not clearly marked failed That combination (workload dies / doesn’t report status, but the UI or higher-level status doesn’t reflect a clear failure) matches the class of bugs where the workload is FAILED internally but the status is not propagated correctly. [Replication pod status bug] Given the knowledge sources, there isn’t a documented, connector-specific fix for your custom Python destination, and they don’t explain why a run with this

Failures: [...]

block would still appear as “not failed” in your UI. So there is some unavoidable uncertainty. Based on what is documented, here’s what you can reliably do: 1. Confirm the sync summary in the same log Scroll further down in the job log and look for a

Sync summary

block. In other issues with similar failures, it looks like:

Sync summary: {
     "status" : "failed",
     ...
   }

[BigQuery exit 1; BigQuery project-id bug] If that summary says

"status": "failed"

but the job/connection is not shown as failed in the UI, you’re very likely hitting the same status‑propagation problem as in the replication‑pod bug. [Replication pod status bug] 2. Open a GitHub issue with evidence Following how similar issues are handled, include: ◦ Airbyte version and deployment (OSS/Cloud, Docker/K8s, etc.). ◦ That

Failures: [...]

block with the

Destination process exited with non-zero exit code 143

. ◦ The

attempts

table row showing

Airbyte could not track the sync progress. Sync process exited without reporting status.

(if present). ◦ The

Sync summary

block from the logs. This is the same type of information maintainers request when investigating status inconsistencies. [Replication pod status bug] 3. Connector-side: ensure hard failure on fatal errors Airbyte’s requirements for partner destinations say: ◦ “Silent errors are not permitted.” ◦ If errors cannot be logged via an approved protocol, the destination must fail and raise the error. [Partner error handling] Your connector is already exiting with a non‑zero code (143), so it’s not “silent” at the process level. But you should still verify that you’re not catching and swallowing fatal exceptions in your Python code in a way that could interfere with proper reporting. Because the knowledge sources don’t contain more detail on exit code 143 handling or on this exact combination (custom Python destination + “could not track progress” + status not marked failed), I can’t give a more precise root cause or code-level fix. The safest, supported path is to treat this as a destination crash that is correctly detected but not correctly surfaced, and escalate it with logs and DB evidence as above. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.