<@U04S8PLJWMT> getting this error multiple times o...
# replication-ask-ai
m
@kapa.ai getting this error multiple times on mongo connector. i tried to make new connections and reset connections many times but it didn't solve the issue. follow the log files for the issue.
k
Sorry @manik.jindal, I encountered an error processing the file(s) you uploaded: Text file is too large (max 60K characters)
m
@kapa.ai screenshot of the error
k
Looking at your screenshot, the error shows: > _Some streams either received an INCOMPLETE stream status, or did not receive a stream status at all: null.mandate_logs, null.nsdl_logs, null.gc_api_logs, null.ucclogs_ >
io.airbyte.commons.exceptions.TransientErrorException: Some streams were unsuccessful due to a source error.
This is a MongoDB source connector issue where streams are failing to sync. Here are the steps to investigate and resolve it: Likely Causes & Fixes 1. Oplog / Resume Token Issue (Most Common) The
TransientErrorException
with incomplete streams on MongoDB is frequently related to an invalid or expired resume token (oplog retention). [MongoDB Troubleshooting] Steps to address: • Reset the connection in Airbyte (clear the saved state) — go to the connection settings and trigger a full reset. • Increase your Oplog retention to at least 24 hours (ideally 7 days) on your MongoDB cluster. [MongoDB Troubleshooting] • Increase sync frequency so the resume token doesn't expire between syncs. For MongoDB Atlas, you can adjust the Oplog size here. 2. Check Your Connector Version There is a known bug in
source-mongodb-v2
versions `2.0.1`–`2.0.3` where the saved state (resume token) can become corrupted or stuck, causing repeated failures. A fix was released in version
2.0.4+
. [GitHub Issue] Action: Upgrade your MongoDB source connector to the latest available version. 3. Switch Failing Streams to Full Refresh If specific streams (like
mandate_logs
,
nsdl_logs
, etc.) continue to fail in Incremental/CDC mode, consider switching them to Full Refresh sync mode as a workaround. Full Refresh does not rely on change streams or the oplog. [MongoDB Troubleshooting] Recommended Action Plan 1. Upgrade the MongoDB source connector to the latest version. 2. Reset the connection state. 3. Verify your Oplog retention is ≥ 24 hours. 4. Increase sync frequency (e.g., every hour or less). 5. If the issue persists on specific streams, switch those to Full Refresh mode. Could you share which connector version you're currently using? That would help narrow down the root cause further. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
@kapa.ai 2026-07-04 073215 replication-orchestrator INFO Sync summary: { "status" : "failed", "recordsSynced" : 0, "bytesSynced" : 0, "startTime" : 1783129920628, "endTime" : 1783130535219, "totalStats" : { "bytesCommitted" : 0, "bytesEmitted" : 0, "destinationStateMessagesEmitted" : 4, "destinationWriteEndTime" : 0, "destinationWriteStartTime" : 1783129929901, "meanSecondsBeforeSourceStateMessageEmitted" : 0, "maxSecondsBeforeSourceStateMessageEmitted" : 1, "maxSecondsBetweenStateMessageEmittedandCommitted" : 120, "meanSecondsBetweenStateMessageEmittedandCommitted" : 120, "recordsEmitted" : 0, "recordsCommitted" : 0, "recordsFilteredOut" : 0, "bytesFilteredOut" : 0, "replicationEndTime" : 1783130535150, "replicationStartTime" : 1783129920628, "sourceReadEndTime" : 0, "sourceReadStartTime" : 1783129929901, "sourceStateMessagesEmitted" : 4 }, "streamStats" : [ { "streamName" : "ucclogs", "streamNamespace" : "gripinvest", "stats" : { "bytesCommitted" : 0, "bytesEmitted" : 0, "estimatedBytes" : 0, "estimatedRecords" : 0, "recordsEmitted" : 0, "recordsCommitted" : 0, "recordsFilteredOut" : 0, "bytesFilteredOut" : 0 } }, { "streamName" : "nsdl_logs", "streamNamespace" : "gripinvest", "stats" : { "bytesCommitted" : 0, "bytesEmitted" : 0, "estimatedBytes" : 0, "estimatedRecords" : 0, "recordsEmitted" : 0, "recordsCommitted" : 0, "recordsFilteredOut" : 0, "bytesFilteredOut" : 0 } }, { "streamName" : "gc_api_logs", "streamNamespace" : "gripinvest", "stats" : { "bytesCommitted" : 0, "bytesEmitted" : 0, "estimatedBytes" : 0, "estimatedRecords" : 0, "recordsEmitted" : 0, "recordsCommitted" : 0, "recordsFilteredOut" : 0, "bytesFilteredOut" : 0 } }, { "streamName" : "mandate_logs", "streamNamespace" : "gripinvest", "stats" : { "bytesCommitted" : 0, "bytesEmitted" : 0, "estimatedBytes" : 0, "estimatedRecords" : 0, "recordsEmitted" : 0, "recordsCommitted" : 0, "recordsFilteredOut" : 0, "bytesFilteredOut" : 0 } } ], "performanceMetrics" : { } } 2026-07-04 073215 replication-orchestrator INFO Failures: [ { "failureOrigin" : "destination", "failureType" : "transient_error", "internalMessage" : "Some streams either received an INCOMPLETE stream status, or did not receive a stream status at all: null.mandate_logs, null.nsdl_logs, null.gc_api_logs, null.ucclogs\nio.airbyte.commons.exceptions.TransientErrorException: Some streams were unsuccessful due to a source error. See logs for details.", "externalMessage" : "Some streams were unsuccessful due to a source error. See logs for details.", "metadata" : { "attemptNumber" : 0, "jobId" : 16415, "from_trace_message" : true, "connector_command" : "write" }, "stacktrace" : "io.airbyte.commons.exceptions.TransientErrorException: Some streams were unsuccessful due to a source error. See logs for details.\n\tat io.airbyte.cdk.integrations.destination.async.AsyncStreamConsumer.close(AsyncStreamConsumer.kt:215)\n\tat io.airbyte.cdk.integrations.base.SerializedAirbyteMessageConsumer$Companion$appendOnClose$1.close(SerializedAirbyteMessageConsumer.kt:70)\n\tat kotlin.jdk7.AutoCloseableKt.closeFinally(AutoCloseableJVM.kt:48)\n\tat io.airbyte.cdk.integrations.base.IntegrationRunner.runInternal(IntegrationRunner.kt:215)\n\tat io.airbyte.cdk.integrations.base.IntegrationRunner.run(IntegrationRunner.kt:119)\n\tat io.airbyte.cdk.integrations.base.IntegrationRunner.run$default(IntegrationRunner.kt:113)\n\tat io.airbyte.integrations.destination.redshift.RedshiftDestination$Companion.main(RedshiftDestination.kt:519)\n\tat io.airbyte.integrations.destination.redshift.RedshiftDestination.main(RedshiftDestination.kt)\n", "timestamp" : 1783130535066 }, { "failureOrigin" : "source", "internalMessage" : "Source process exited with non-zero exit code 2", "externalMessage" : "Something went wrong within the source connector", "metadata" : { "attemptNumber" : 0, "jobId" : 16415, "connector_command" : "read" }, "stacktrace" : "io.airbyte.workers.internal.exception.SourceException: Source process exited with non-zero exit code 2\n\tat io.airbyte.container.orchestrator.worker.SourceReader.run(ReplicationTask.kt:206)\n\tat io.airbyte.container.orchestrator.worker.SourceReader$run$1.invokeSuspend(ReplicationTask.kt)\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" : 1783130535149 } ] 2026-07-04 073215 replication-orchestrator INFO 2026-07-04 073215 replication-orchestrator INFO ----- END REPLICATION ----- 2026-07-04 073215 replication-orchestrator INFO 2026-07-04 073215 replication-orchestrator INFO Closing io.micronaut.context.propagation.instrument.execution.ContextPropagatingExecutorService@510e0dd2 2026-07-04 073215 replication-orchestrator INFO Closing io.airbyte.container.orchestrator.worker.io.LocalContainerAirbyteDestination@54a98358 2026-07-04 073215 replication-orchestrator ERROR Error closing resource io.airbyte.container.orchestrator.worker.io.LocalContainerAirbyteDestination@54a98358; recording failure but continuing. 2026-07-04 073215 replication-orchestrator INFO Closing io.airbyte.container.orchestrator.worker.io.LocalContainerAirbyteSource@58c93be3 2026-07-04 073215 replication-orchestrator ERROR Error closing resource io.airbyte.container.orchestrator.worker.io.LocalContainerAirbyteSource@58c93be3; recording failure but continuing. 2026-07-04 073215 replication-orchestrator INFO Closing io.airbyte.container.orchestrator.worker.RecordSchemaValidator@6e669b5c 2026-07-04 073215 replication-orchestrator INFO Closing io.airbyte.container.orchestrator.persistence.SyncPersistenceImpl@3db3668 2026-07-04 073215 replication-orchestrator INFO Returning output... 2026-07-04 073216 platform INFO ----- START POST REPLICATION OPERATIONS ----- 2026-07-04 073220 platform INFO No post-replication operation(s) to perform. 2026-07-04 073220 platform INFO ----- END POST REPLICATION OPERATIONS ----- 2026-07-04 073220 platform INFO Retry State: RetryManager(completeFailureBackoffPolicy=BackoffPolicy(minInterval=PT10S, maxInterval=PT30M, base=3), partialFailureBackoffPolicy=null, successiveCompleteFailureLimit=5, successivePartialFailureLimit=1000, totalCompleteFailureLimit=10, totalPartialFailureLimit=20, successiveCompleteFailures=1, successivePartialFailures=0, totalCompleteFailures=1, totalPartialFailures=0) Backoff before next attempt: 10 seconds
k
Your logs confirm the exact root cause:
Copy code
"failureOrigin" : "source",
"internalMessage" : "Source process exited with non-zero exit code 2"
This is a known bug in
source-mongodb-v2
where a CDC sync exits with code 2 due to the Debezium
replicator-fetcher
thread being unable to terminate cleanly on shutdown — even though the sync itself completed successfully (state was committed, resume token saved). [GitHub Issue #80207] [GitHub Issue #80211] What's Happening 1. Your streams (
mandate_logs
,
nsdl_logs
,
gc_api_logs
,
ucclogs
) are low-traffic collections — no writes arrive during the sync window. 2. After the idle timeout (20 min), Debezium closes the engine and commits the resume token correctly. 3. However, the
replicator-fetcher-0
thread remains blocked in a MongoDB socket read that cannot be interrupted. 4.
IntegrationRunner.stopOrphanedThreads
waits, then force-exits with code 2, causing a false failure. [GitHub Issue #80211] Your sync summary confirms this — 0 records but 4 state messages emitted, meaning the sync actually completed fine but was reported as failed. Fix A fix was merged in PR #80213 that bumps the connector from
2.0.7
→
2.0.8
. It registers an orphaned thread filter to exclude the
replicator-fetcher
thread from the force-exit logic:
Copy code
IntegrationRunner.addOrphanedThreadFilter(
    threadInfo -> !threadInfo.getThread().getName().contains("replicator-fetcher")
);
[PR #80213] What You Should Do 1. Upgrade
source-mongodb-v2
to version
2.0.8
(or latest) — this is the primary fix. 2. Do NOT reset the connection — your state/resume token is valid and was committed correctly. Resetting will trigger a full re-snapshot unnecessarily. 3. The repeated failures you see are false failures — your data and state are intact. > Note: The
maxSecondsBetweenStateMessageEmittedandCommitted: 120
in your logs is consistent with the orphaned-thread grace period before the force-exit, further confirming this diagnosis. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
@kapa.ai what is the latest available version of mongodb connector
k
Based on the knowledge sources available to me, the latest version documented in the changelog is
2.0.7
(released 2026-01-21). [MongoDB Changelog] However, based on the GitHub PRs also provided in the knowledge sources, version
2.0.8
is in progress/recently merged, which improves CDC authorization error handling. [PR #77960] I cannot confirm with certainty whether
2.0.8
has been officially released yet, as it does not appear in the published changelog. I'd recommend checking the official MongoDB V2 connector changelog directly for the most up-to-date version information. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
@kapa.ai we are using v2.0.7 but the issue is still there. is this issue get fixed in v2.0.8?
k
Yes, based on the knowledge sources, the exit code 2 issue you are experiencing on
v2.0.7
is specifically fixed in
v2.0.8
. The fix is in PR #80213, which: • Bumps the connector from
2.0.7
→
2.0.8
• Registers an orphaned thread filter to exclude the
replicator-fetcher
thread from force-exit detection:
Copy code
IntegrationRunner.addOrphanedThreadFilter(
    threadInfo -> !threadInfo.getThread().getName().contains("replicator-fetcher")
);
The PR description explicitly states: > "Syncs that previously appeared to fail with exit code 2 (despite completing successfully) will now complete without the spurious force-exit. No user action required." [PR #80213] Summary However, I cannot confirm with certainty whether
2.0.8
has been officially released yet, as my knowledge sources do not include the final published changelog. I'd recommend: 1. Checking the MongoDB V2 connector changelog to confirm
2.0.8
is available. 2. If available, upgrading to
2.0.8
should resolve your issue without any connection reset needed. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
m
@kapa.ai i checked v.2.0.8 is not avaible how long will it take to get releases?
k
I'm sorry, but the knowledge sources do not contain any information about the expected release timeline for
v2.0.8
of the MongoDB connector. For the most accurate ETA, I'd recommend: 1. Watch/comment on the PR directly — PR #80213 is the fix for your issue. You can track its merge and release status there. 2. Open a GitHub issue or comment on the existing issue #80207 to express urgency — the Airbyte team monitors these. 3. Contact Airbyte Support directly at support.airbyte.com for an official timeline. In the Meantime As a workaround, since your syncs are actually succeeding (state is committed correctly), you could: • Increase the sync frequency to reduce idle time on low-traffic collections, which may reduce how often the orphaned thread issue triggers. • Switch the affected streams (
mandate_logs
,
nsdl_logs
,
gc_api_logs
,
ucclogs
) to Full Refresh mode temporarily — this avoids CDC/change stream entirely and won't be affected by the
replicator-fetcher
bug. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.