https://linen.dev logo
Join Slack
Powered by
<@U04S8PLJWMT> what is this 2025-12-30 16:01:31 re...
# replication-ask-ai
i
@kapa.ai what is this 2025-12-30 160131 replication-orchestrator INFO SOURCE analytics [airbyte/source-mongodb-v2:2.0.4] | Type: db-sources-debezium-close-reason | Value: TIMEOUT related to ?
k
This log line is indicating why the MongoDB v2 Debezium-based source connector closed, and the 
Value: TIMEOUT
is the close reason. From the platform side, Airbyte monitors “heartbeats” (records or state messages) from the source; if no message is seen for longer than the configured threshold (
heartbeat-max-seconds-between-messages
in 
flags.yaml
), the sync is failed with an internal heartbeat timeout and the source is considered unresponsive.[\[Heartbeats](https://docs.airbyte.com/platform/understanding-airbyte/heartbeats#technical-details)] In your case, the Debezium-based MongoDB v2 connector is reporting that it is closing due to a timeout condition, which is consistent with that heartbeat/timeout mechanism. The knowledge sources do not provide a more detailed, connector‑specific definition of the 
db-sources-debezium-close-reason
values, so beyond this general timeout/heartbeat explanation, there’s no further official detail available.
i
It failed becaus eof this... @kapa.ai 025-12-30 161556 source INFO main i.a.c.i.d.i.DebeziumRecordIterator(computeNext):87 CDC events queue poll(): blocked for PT5M0.000726221S in its first call. 2025-12-30 161556 source INFO main i.a.c.i.d.i.DebeziumRecordIterator(computeNext):108 CDC events queue poll(): returned nothing. 2025-12-30 161556 source INFO main i.a.c.i.d.i.DebeziumRecordIterator(requestClose):275 No records were returned by Debezium in the timeout seconds 300, closing the engine and iterator 2025-12-30 161556 replication-orchestrator INFO SOURCE analytics
k
A message from kapa.ai
Those log lines mean the MongoDB v2 CDC (Debezium) engine started, waited 5 minutes for any change events, and got no records at all, so Airbyte timed out and shut the source down. Concretely:
Copy code
text CDC events queue poll(): blocked for PT5M0.000726221S in its first call. CDC events queue poll(): returned nothing. No records were returned by Debezium in the timeout seconds 300, closing the engine and iterator
This is the DebeziumRecordIterator saying: - It waited 300 seconds (5 minutes) for Debezium to put any CDC events into its internal queue. - Nothing arrived (no change events, no heartbeats). - Because of that, it closed the Debezium engine with a timeout close reason, which is what you see as 
db-sources-debezium-close-reason | Value: TIMEOUT
in the other log. [[Saved offset issue](https://github.com/airbytehq/airbyte/issues/70222)] The knowledge sources don’t provide additional MongoDB‑specific causes beyond this generic behavior: if Debezium doesn’t emit any records within the configured timeout window, Airbyte treats it as a timeout and stops the sync.
i
@kapa.ai I don;t understand this, this wasn't present before and it suddenlt started to behave like this, I ran a sync which took 4 hours, then stopped for an issue, not everytime I run it looks like this, why doees this issue persist 2025-12-30 161556 source INFO main i.a.c.i.d.i.DebeziumRecordIterator(computeNext):87 CDC events queue poll(): blocked for PT5M0.000726221S in its first call. 2025-12-30 161556 source INFO main i.a.c.i.d.i.DebeziumRecordIterator(computeNext):108 CDC events queue poll(): returned nothing. 2025-12-30 161556 source INFO main i.a.c.i.d.i.DebeziumRecordIterator(requestClose):275 No records were returned by Debezium in the timeout seconds 300, closing the engine and iterator 2025-12-30 161556 replication-orchestrator INFO SOURCE analytics [airbyte/source-mongodb-v2:2.0.4] | Type: db-sources-debezium-close-reason | Value: TIMEOUT 2025-12-30 161556 source INFO main i.d.e.EmbeddedEngine(stop):957 Stopping the embedded engine 2025-12-30 161556 replication-orchestrator INFO SOURCE analytics [airbyte/source-mongodb-v2:2.0.4] | Type: debezium-shutdown-error | Value: 1 2025-12-30 161556 source ERROR main i.a.c.i.u.ConnectorExceptionHandler(handleException):68 caught exception! io.airbyte.cdk.integrations.source.relationaldb.state.FailedRecordIteratorException: java.lang.RuntimeException: java.lang.RuntimeException: org.apache.kafka.connect.errors.ConnectException: An exception occurred in the change event producer. This connector will be stopped. at io.airbyte.cdk.integrations.source.relationaldb.state.SourceStateIterator.computeNext(SourceStateIterator.kt:38) ~[airbyte-cdk-db-sources-0.48.9.jar:?] at io.airbyte.cdk.integrations.source.relationaldb.state.SourceStateIterator.computeNext(SourceStateIterator.kt:18) ~[airbyte-cdk-db-sources-0.48.9.jar:?] at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:145) ~[guava-33.3.0-jre.jar:?] at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:140) ~[guava-33.3.0-jre.jar:?] at io.airbyte.commons.util.DefaultAutoCloseableIterator.computeNext(DefaultAutoCloseableIterator.kt:42) ~[airbyte-cdk-dependencies-0.48.9.jar:?] at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:145) ~[guava-33.3.0-jre.jar:?] at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:140) ~[guava-33.3.0-jre.jar:?] at io.airbyte.commons.util.LazyAutoCloseableIterator.computeNext(LazyAutoCloseableIterator.kt:45) ~[airbyte-cdk-dependencies-0.48.9.jar:?] at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:145) ~[guava-33.3.0-jre.jar:?] at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:140) ~[guava-33.3.0-jre.jar:?] at io.airbyte.commons.util.CompositeIterator.computeNext(CompositeIterator.kt:67) ~[airbyte-cdk-dependencies-0.48.9.jar:?] at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:145) ~[guava-33.3.0-jre.jar:?] at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:140) ~[guava-33.3.0-jre.jar:?] at java.base/java.util.Iterator.forEachRemaining(Iterator.java:132) ~[?:?] at io.airbyte.cdk.integrations.base.IntegrationRunner.produceMessages(IntegrationRunner.kt:234) ~[airbyte-cdk-core-0.48.9.jar:?] at io.airbyte.cdk.integrations.base.IntegrationRunner.readSerial(IntegrationRunner.kt:291) ~[airbyte-cdk-core-0.48.9.jar:?] at io.airbyte.cdk.integrations.base.IntegrationRunner.runInternal(IntegrationRunner.kt:190) [airbyte-cdk-core-0.48.9.jar:?] at io.airbyte.cdk.integrations.base.IntegrationRunner.run(IntegrationRunner.kt:119) [airbyte-cdk-core-0.48.9.jar:?] at io.airbyte.cdk.integrations.base.IntegrationRunner.run$default(IntegrationRunner.kt:113) [airbyte-cdk-core-0.48.9.jar:?] at io.airbyte.cdk.integrations.base.IntegrationRunner.run(IntegrationRunner.kt) [airbyte-cdk-core-0.48.9.jar:?] at io.airbyte.integrations.source.mongodb.MongoDbSource.main(MongoDbSource.java:53) [io.airbyte.airbyte-integrations.connectors-source-mongodb-v2.jar:?] Caused by: java.lang.RuntimeException: java.lang.RuntimeException: org.apache.kafka.connect.errors.ConnectException: An exception occurred in the change event producer. This connector will be stopped. at io.airbyte.cdk.integrations.debezium.internals.DebeziumShutdownProcedure.initiateShutdownProcedure(DebeziumShutdownProcedure.kt:95) ~[airbyte-cdk-db-sources-0.48.9.jar:?] at io.airbyte.cdk.integrations.debezium.internals.DebeziumRecordIterator.requestClose(DebeziumRecordIterator.kt:279) ~[airbyte-cdk-db-sources-0.48.9.jar:?] at io.airbyte.cdk.integrations.debezium.internals.DebeziumRecordIterator.computeNext(DebeziumRecordIterator.kt:112) ~[airbyte-cdk-db-sources-0.48.9.jar:?] at io.airbyte.cdk.integrations.debezium.internals.DebeziumRecordIterator.computeNext(DebeziumRecordIterator.kt:37) ~[airbyte-cdk-db-sources-0.48.9.jar:?] at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:145) ~[guava-33.3.0-jre.jar:?] at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:140) ~[guava-33.3.0-jre.jar:?] at io.airbyte.cdk.integrations.source.relationaldb.state.SourceStateIterator.computeNext(SourceStateIterator.kt:32) ~[airbyte-cdk-db-sources-0.48.9.jar:?] ... 20 more Caused by: java.lang.RuntimeException: org.apache.kafka.connect.errors.ConnectException: An exception occurred in the change event producer. This connector will be stopped. at io.airbyte.cdk.integrations.debezium.internals.DebeziumRecordPublisher.close(DebeziumRecordPublisher.kt:124) ~[airbyte-cdk-db-sources-0.48.9.jar:?] at io.airbyte.cdk.integrations.debezium.AirbyteDebeziumHandler.getIncrementalIterators$lambda$1(AirbyteDebeziumHandler.kt:108) ~[airbyte-cdk-db-sources-0.48.9.jar:?] at io.airbyte.commons.concurrency.VoidCallable.call(VoidCallable.kt:12) ~[airbyte-cdk-dependencies-0.48.9.jar:?] at io.airbyte.cdk.integrations.debezium.internals.DebeziumShutdownProcedure.initiateShutdownProcedure(DebeziumShutdownProcedure.kt:91) ~[airbyte-cdk-db-sources-0.48.9.jar:?] at io.airbyte.cdk.integrations.debezium.internals.DebeziumRecordIterator.requestClose(DebeziumRecordIterator.kt:279) ~[airbyte-cdk-db-sources-0.48.9.jar:?] at io.airbyte.cdk.integrations.debezium.internals.DebeziumRecordIterator.computeNext(DebeziumRecordIterator.kt:112) ~[airbyte-cdk-db-sources-0.48.9.jar:?] at io.airbyte.cdk.integrations.debezium.internals.DebeziumRecordIterator.computeNext(DebeziumRecordIterator.kt:37) ~[airbyte-cdk-db-sources-0.48.9.jar:?] at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:145) ~[guava-33.3.0-jre.jar:?] at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:140) ~[guava-33.3.0-jre.jar:?] at io.airbyte.cdk.integrations.source.relationaldb.state.SourceStateIterator.computeNext(SourceStateIterator.kt:32) ~[airbyte-cdk-db-sources-0.48.9.jar:?] ... 20 more Caused by: org.apache.kafka.connect.errors.ConnectException: An exception occurred in the change event producer. This connector will be stopped. at io.debezium.pipeline.ErrorHandler.setProducerThrowable(ErrorHandler.java:67) ~[debezium-core-2.6.2.Final.jar:2.6.2.Final] at io.debezium.connector.mongodb.MongoDbStreamingChangeEventSource.execute(MongoDbStreamingChangeEventSource.java:91) ~[debezium-connector-mongodb-2.6.2.Final.jar:2.6.2.Final] at io.debezium.connector.mongodb.MongoDbStreamingChangeEventSource.execute(MongoDbStreamingChangeEventSource.java:38) ~[debezium-connector-mongodb-2.6.2.Final.jar:2.6.2.Final] at io.debezium.pipeline.ChangeEventSourceCoordinator.streamEvents(ChangeEventSourceCoordinator.java:280) ~[debezium-core-2.6.2.Final.jar:2.6.2.Final] at io.debezium.pipeline.ChangeEventSourceCoordinator.executeChangeEventSources(ChangeEventSourceCoordinator.java:197) ~[debezium-core-2.6.2.Final.jar:2.6.2.Final] at io.debezium.pipeline.ChangeEventSourceCoordinator.lambda$start$0(ChangeEventSourceCoordinator.java:140) ~[debezium-core-2.6.2.Final.jar:2.6.2.Final] at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572) ~[?:?] at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317) ~[?:?] at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[?:?] at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[?:?] at java.base/java.lang.Thread.run(Thread.java:1583) ~[?:?] Caused by: io.debezium.DebeziumException: Error while attempting to Reading change stream at io.debezium.connector.mongodb.connection.MongoDbConnections.lambda$eventSourcingErrorHandler$1(MongoDbConnections.java:53) ~[debezium-connector-mongodb-2.6.2.Final.jar:2.6.2.Final] at io.debezium.connector.mongodb.connection.MongoDbConnection.execute(MongoDbConnection.java:111) ~[debezium-connector-mongodb-2.6.2.Final.jar:2.6.2.Final] at io.debezium.connector.mongodb.connection.MongoDbConnection.execute(MongoDbConnection.java:88) ~[debezium-connector-mongodb-2.6.2.Final.jar:2.6.2.Final] at io.debezium.connector.mongodb.MongoDbStreamingChangeEventSource.execute(MongoDbStreamingChangeEventSource.java:85) ~[debezium-connector-mongodb-2.6.2.Final.jar:2.6.2.Final] at io.debezium.connector.mongodb.MongoDbStreamingChangeEventSource.execute(MongoDbStreamingChangeEventSource.java:38) ~[debezium-connector-mongodb-2.6.2.Final.jar:2.6.2.Final] at io.debezium.pipeline.ChangeEventSourceCoordinator.streamEvents(ChangeEventSourceCoordinator.java:280) ~[debezium-core-2.6.2.Final.jar:2.6.2.Final] at io.debezium.pipeline.ChangeEventSourceCoordinator.executeChangeEventSources(ChangeEventSourceCoordinator.java:197) ~[debezium-core-2.6.2.Final.jar:2.6.2.Final] at io.debezium.pipeline.ChangeEventSourceCoordinator.lambda$start$0(ChangeEventSourceCoordinator.java:140) ~[debezium-core-2.6.2.Final.jar:2.6.2.Final] at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572) ~[?:?] at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317) ~[?:?] at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[?:?] at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[?:?] at java.base/java.lang.Thread.run(Thread.java:1583) ~[?:?] Caused by: io.debezium.DebeziumException: Unable to fetch change stream events at io.debezium.connector.mongodb.events.BufferingChangeStreamCursor$EventFetcher.poll(BufferingChangeStreamCursor.java:196) ~[debezium-connector-mongodb-2.6.2.Final.jar:2.6.2.Final] at io.debezium.connector.mongodb.events.BufferingChangeStreamCursor.pollWithDelay(BufferingChangeStreamCursor.java:363) ~[debezium-connector-mongodb-2.6.2.Final.jar:2.6.2.Final] at io.debezium.connector.mongodb.events.BufferingChangeStreamCursor.tryNext(BufferingChangeStreamCursor.java:331) ~[debezium-connector-mongodb-2.6.2.Final.jar:2.6.2.Final] at io.debezium.connector.mongodb.MongoDbStreamingChangeEventSource.readChangeStream(MongoDbStreamingChangeEventSource.java:108) ~[debezium-connector-mongodb-2.6.2.Final.jar:2.6.2.Final] at io.debezium.connector.mongodb.MongoDbStreamingChangeEventSource.lambda$execute$0(MongoDbStreamingChangeEventSource.java:86) ~[debezium-connector-mongodb-2.6.2.Final.jar:2.6.2.Final] at io.debezium.connector.mongodb.connection.MongoDbConnection.lambda$execute$0(MongoDbConnection.java:89) ~[debezium-connector-mongodb-2.6.2.Final.jar:2.6.2.Final] at io.debezium.connector.mongodb.connection.MongoDbConnection.execute(MongoDbConnection.java:105) ~[debezium-connector-mongodb-2.6.2.Final.jar:2.6.2.Final] at io.debezium.connector.mongodb.connection.MongoDbConnection.execute(MongoDbConnection.java:88) ~[debezium-connector-mongodb-
k
A message from kapa.ai
I’m sorry, but the knowledge sources don’t contain enough information to explain why this suddenly started happening in your environment or to fully interpret this specific Debezium/MongoDB error chain. They only cover a different MongoDB v2 CDC issue (the 
replicaSet
parameter bug) and some generic Debezium timeout/close behavior, not the detailed “Unable to fetch change stream events” failure you’re seeing now.[[MongoDB v2 issue](https://github.com/airbytehq/airbyte/issues/63300); [MongoDB v2 changelog](https://docs.airbyte.com/integrations/sources/mongodb-v2#changelog)] From what is documented: - MongoDB v2 uses Debezium for CDC; when Debezium encounters an internal error in the change-event producer, Airbyte wraps it as a 
FailedRecordIteratorException
and shuts down the iterator. That’s the pattern you see in your stack trace (Debezium error → `DebeziumRecordPublisher`/`DebeziumRecordIterator` → 
FailedRecordIteratorException
).[[MongoDB v2 issue](https://github.com/airbytehq/airbyte/issues/63300)] - Separately, there is a known open bug where the MongoDB v2 connector can mis-handle replica set configuration for self‑managed replica sets, causing Debezium to fail to connect properly for CDC. In that case, Debezium logs connection/validation errors and the sync fails during incremental CDC.[[MongoDB v2 issue](https://github.com/airbytehq/airbyte/issues/63300)] However: - Your logs show 
Unable to fetch change stream events
and 
Error while attempting to Reading change stream
, which look like a lower‑level MongoDB change stream problem (network, permissions, topology, or server‑side issue), but the provided docs don’t describe this scenario or its root causes. - The docs also don’t describe any change in 2.0.4 that would directly explain a new, persistent “Unable to fetch change stream events” error after a long initial sync; 2.0.4 is documented as adding state format validation only.[[MongoDB v2 changelog](https://docs.airbyte.com/integrations/sources/mongodb-v2#changelog)] Given these limits, I can’t reliably say: - Why your 4‑hour run worked and then stopped. - Why every subsequent run now immediately hits this Debezium/MongoDB change stream error. - Whether this is due to connector configuration, MongoDB server state, or an environmental change. To move forward, you’ll likely need to: 1. Inspect MongoDB server logs around the time of the failure for change stream / cursor / auth / network errors. 2. Double‑check your MongoDB v2 source configuration (especially replica set / connection string) against the known replica set bug described in the GitHub issue.[[MongoDB v2 issue](https://github.com/airbytehq/airbyte/issues/63300)] 3. If possible, open or update a GitHub issue with these exact logs so the Airbyte team can correlate them with existing MongoDB v2 CDC issues. I’m constrained to what’s in the knowledge sources, so I can’t go beyond this without guessing.
i
@kapa.ai Caused by: com.mongodb.MongoCommandException: Command failed with error 51091 (Location51091): 'Regular expression is invalid: pattern string is longer than the limit set by the application' on server uae-preprod-1-shard-00-01-pri.7qnhs.mongodb.net:27017. The full response is {"ok": 0.0, "errmsg": "Regular expression is invalid: pattern string is longer than the limit set by the application", "code": 51091, "codeName": "Location51091", "$clusterTime": {"clusterTime": {"$timestamp": {"t": 1767102145, "i": 5}}, "signature": {"hash": {"$binary": {"base64": "MjNNdAqDF35BGlKz5nfppccHi3M=", "subType": "00"}}, "keyId": 7558908708839751682}}, "operationTime": {"$timestamp": {"t": 1767102145, "i": 5}}}
k
A message from kapa.ai
The knowledge sources don’t mention this specific MongoDB error code 
51091
, so I can’t give a connector‑specific root cause with certainty. I can, however, relate it to how the MongoDB v2 source works. Your stack trace shows: > 
MongoCommandException: ... "Regular expression is invalid: pattern string is longer than the limit set by the application" ... code 51091
This is coming directly from MongoDB when the connector runs a command that includes a 
$regex
filter whose pattern string is too long for MongoDB’s internal limit. The error then bubbles up through Debezium (
Unable to fetch change stream events
) and causes the CDC engine to stop, which is why you see the Debezium timeout/close behavior and the sync failure. In the available docs/issues: - There are known MongoDB v2 problems around CDC and Debezium (e.g., replica set handling, oplog/offset issues), but none mention regex length or error 51091.[[MongoDB v2 issue](https://github.com/airbytehq/airbyte/issues/63300); [Saved offset issue](https://github.com/airbytehq/airbyte/issues/70222)] - The troubleshooting guide talks about oplog/change stream limitations and general CDC failures, but not regex‑related errors.[[MongoDB v2 troubleshooting](https://docs.airbyte.com/integrations/sources/mongodb-v2/mongodb-v2-troubleshooting#connector-limitations)] Because this regex error is not documented for the connector, I can’t say from the knowledge sources: - Which exact query the connector is issuing that contains this regex. - Whether this is a bug in the connector’s query construction, or triggered by specific data/field names in your collections. Given the constraints of the docs, the most I can reliably say is: - The immediate cause of your failure is MongoDB rejecting a command due to an over‑long regular expression pattern (
code 51091
). - That error propagates through Debezium and causes the MongoDB v2 CDC sync to stop. - There is no existing Airbyte documentation or GitHub issue in the provided sources that describes this particular regex‑length problem for 
source-mongodb-v2
. To get this resolved, you’ll likely need to: 1. Enable more verbose logging on the MongoDB side to see which command (and which collection/field) is using that regex. 2. Open or update a GitHub issue for 
source-mongodb-v2
with this full stack trace and error payload, since it appears to be a new/undocumented failure mode relative to the current MongoDB v2 docs and issues.
11 Views
Open in Slack
PreviousNext
Powered by