@kapa.ai What is going wrong here, and what is the recommended long-term fix? Error occurred:

io.airbyte.cdk.TransientErrorException: Input was fully read, but some streams did not receive a terminal stream status message. If the destination did not encounter other errors, this likely indicates an error in the source or platform. Streams without a status message

What's wrong: Airbyte's

source-mongodb-v2

buffers CDC records by count, not by bytes. Our collection documents average 22 KB (up to 175 KB) with heavy internal duplication. During bursts, the source JVM fills its 12 Gi container limit within 30–60 seconds and gets OOM-killed. The log says "source failed" but the destination is fine—it dies as a side effect. Confirmed via live memory readings: 12K burst → source hits 11.3 GiB → OOM 15K burst → source hits 11.6 GiB → OOM Destination stays at ~600 MiB throughout (5% of its limit) Known Airbyte bugs matching our workload: Issue #3439 (open since 2021) — record-count batching breaks for large rows. Airbyte team quote: "any DB Source with a large average row size will run into this issue." Issue #74802 — v3

destination-bigquery

fails terminal status on large streams. What we've done: • Applied a 15 Gi memory override to the connection → 30K bursts succeed. • Confirmed Post Image mode isn't the memory fix (same ceiling). • Confirmed queue cap tuning doesn't help (MongoDB queue size configuration). • Tested up to 80K records, which still failed the sync. What is the recommended long-term fix for this workload instead of simply increasing container memory?

The knowledge sources provide partial but relevant information here. Let me be upfront about what is and isn't confirmed. What's Going Wrong Your diagnosis is correct. The Airbyte Java CDK's internal Debezium event queue (

CapacityReportingBlockingQueue

) was bounded only by element count (default 10,000 items), with no byte-size limit. With large documents (your 22–175 KB average), the queue alone can consume enormous heap: > "With ~833KB events, the queue alone can require 10,000 × 833KB ≈ 8.3 GB, which exceeds the ~6 GiB heap on an 8Gi container → OOM." [CDK OOM Fix PR] The

TransientErrorException: Input was fully read, but some streams did not receive a terminal stream status message

is a downstream symptom — the destination correctly detects that the source was OOM-killed mid-stream and never sent a terminal status. The destination itself is fine (as your memory readings confirm). [CDK OOM Fix PR] The Long-Term Fix (Already in Progress) PR #81456 directly addresses this root cause: • Byte-bounded queue backpressure:

CapacityReportingBlockingQueue

now tracks approximate heap footprint of queued elements via a

bytesEstimator

(

value().length * 2

for CDC JSON strings). •

put()

blocks when

currentBytes + elementBytes > maxSizeInBytes

, unless the queue is empty (to prevent deadlock on a single oversized event). • Default byte budget: 25% of JVM max heap (~1.5 GB on a 6 GiB heap), matching Debezium's own internal

max.queue.size.in.bytes

guard. • The existing 10,000-count cap is retained as a secondary limit. [CDK OOM Fix PR] Important caveat: As of the PR,

source-mongodb-v2

was pinned to CDK

0.48.9

, and the fix is in CDK

0.48.19

. A follow-up connector version bump is required before the fix reaches production. [CDK OOM Fix PR] What You Can Do Now While waiting for the CDK bump to ship in `source-mongodb-v2`: 1. Keep the memory override (your 15 Gi workaround is valid short-term). 2. Switch large-document streams to Full Refresh instead of Incremental/CDC — Full Refresh does not use change streams and avoids the CDC event size problem entirely. [MongoDB Troubleshooting] 3. Switch from Post Image (

change_streams_update_full_with_pre_image

) to Lookup mode — Lookup retrieves the current document state separately, which reduces the size of individual change stream events. [MongoDB Troubleshooting] 4. Restructure large documents to reduce per-document size if feasible. [MongoDB Troubleshooting] Summary The correct long-term fix is the byte-bounded backpressure in PR #81456 — track the

source-mongodb-v2

connector release that picks up CDK ≥ 0.48.19 to get the fix without needing a memory override. [CDK OOM Fix PR] 👍 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

.

I'm sorry, but the knowledge sources do not contain any information about a planned release date for the

source-mongodb-v2

connector version that picks up CDK ≥ 0.48.19. What the sources do confirm is that as of PR #81456, the connector was still pinned to CDK

0.48.9

and a follow-up connector version bump was explicitly noted as required — but no timeline was given. [CDK OOM Fix PR] For the most accurate ETA, I'd recommend: • Watching PR #81456 on GitHub for merge/release activity. • Opening a support ticket at support.airbyte.com if you're on Airbyte Cloud, referencing that PR. • Joining the Airbyte Community Slack to ask the team directly. 👍 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 what is the latest update on this fix?

Thinking completed I couldn't find a status update for PR #81456 (the byte-bounded queue fix I cited earlier) in the current knowledge sources, so I can't confirm whether the connector bump shipped. Several related PRs do bear on your workload, though. Most relevant: the Debezium connector is being replaced PR #88383 is still open. It rewrites

source-mongodb-v2

as 3.0.0 on the Bulk CDK, with native change-stream CDC instead of Debezium. Existing connections would upgrade without a reset, and legacy Debezium resume tokens are read as-is. [Bulk CDK rewrite] • Debezium and its count-bounded event queue are removed in this design. However, the PR does not mention memory use, OOM, or byte-based buffering, so I can't confirm it fixes your problem. • It is not merge-ready. It targets a mirror branch, and the checklist still lists setting the final PR number and date, a wire-level Unix-socket test, and terabyte-scale validation. [Bulk CDK rewrite] • Autopilot progressive rollout is enabled for it, so a release would likely roll out gradually. [Rollout notice] Other related changes • Queue floor (#82138): it lowers the minimum configured CDC queue size to 64, so small queue sizes are honored for large events instead of being expanded to 1,000. The sources don't show its merge status. [Queue size fix] • Namespace matching (#87574, open): it fixes CDC stalling at 101 records and exiting with code 2 when non-synced collections in the same database are write-heavy. This is a different failure from OOM, but it can look similar. [CDC namespace fix] • Initial-load hardening (#87019, merged): it released 2.1.1 and notes that this connector version is "about to be sunset". [Iterator hardening] Recommendation Keep your memory override for now. Watch #88383 and check whether the 3.0.0 release notes address memory behavior for large documents. For a definitive answer, ask Airbyte support or the community Slack about the status of #81456 and the 3.0.0 rollout. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.