https://linen.dev logo
Join Slack
Powered by
<@U04S8PLJWMT> Running into an issue with a connec...
# replication-ask-ai
j
@kapa.ai Running into an issue with a connection from hubspot to redshift, think this issue is mainly related to redshift destination (on OSS with redshift destintion v3.5.4. I see the destination logs successfully write the temp table, however the replication orchestrator never marks the stream as complete. All other streams in the job get successfully marked as completed. The job stays in a queued status and logs loop on When I run the same stream alone, it works fine. Bumping orchestrator / job memory and cpu hasn’t seemed to had an effect. Logs in thread
k
Based on the knowledge sources available, your issue — where the Redshift destination successfully writes temp tables but the replication orchestrator never marks a specific stream as complete, causing the job to hang — matches a few known patterns in Airbyte. What the knowledge sources suggest 1. Redshift destination hanging after "Executing finalization of tables" There's a documented case of Redshift destinations hanging indefinitely after temp table writes, where the sync never completes. In that case, the root cause was a sidecar container added to pods that wasn't being closed, which caused the hang. Disabling the sidecar resolved it. [Redshift Destination Hanging] 2. Streams without a terminal status message There's a known issue where certain streams never receive a terminal stream status message, causing the destination to throw: > 
TransientErrorException: Input was fully read, but some streams did not receive a terminal stream status message.
This has been observed across multiple connectors and destinations, and is sometimes traced back to the source or platform rather than the destination itself. [Streams without status message; HubSpot Auth Failures] 3. HubSpot source-specific looping issues There are also known bugs in the HubSpot source connector (starting around v5.4.0) where certain streams get stuck in a loop, fetching far more records than expected. This could cause the orchestrator to appear stuck waiting for the source to finish. [HubSpot line_item loop] Recommendations Given the knowledge sources, here are the most relevant things to investigate: 1. Check for sidecar containers on your job/worker pods — if you're running on Kubernetes with any injected sidecars (e.g., service mesh proxies like Istio/Envoy), ensure they are being properly terminated when the job completes. 2. Check the HubSpot source connector version — if you're on v5.4.0 or later, the specific stream may be caught in a pagination loop on the source side, not the destination. Downgrading to v5.3.0 has been reported to resolve looping issues. [HubSpot line_item loop] 3. Isolate whether the issue is source or destination — since the stream works fine when run alone, the issue may be related to how the orchestrator handles multiple concurrent streams, or a specific stream in the batch causing the terminal status message to never be emitted. The knowledge sources don't contain enough detail about Redshift destination v3.5.4 specifically to give a definitive answer, so I'd recommend checking the Airbyte GitHub issues for that version and sharing your logs there for further investigation. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
j
How would you disable sidecar?
(using helm deployment) @kapa.ai
k
Thanks for the additional context. Since you're on a Helm-based Kubernetes deployment, the most directly relevant finding from the knowledge sources is: > A Redshift destination hanging issue was resolved by identifying that a sidecar container was being injected into all pods but was not being closed when the job finished. Disabling the sidecar stopped the hangs entirely. [Redshift Destination Hanging] This is a common pattern in Kubernetes/Helm deployments where service mesh tools (e.g., Istio, Linkerd, or Envoy) inject sidecar proxies into job pods. If the sidecar doesn't terminate when the main container finishes, the orchestrator can hang waiting for the pod to fully complete. What to check: • Inspect your job pods for any injected sidecar containers (e.g., 
istio-proxy
, 
linkerd-proxy
). • If present, configure your Helm chart or namespace to either exclude job pods from sidecar injection, or ensure sidecars are terminated when the main container exits. Beyond that, the knowledge sources don't contain additional Helm-specific details for your exact scenario (Redshift v3.5.4, single stream hanging in a multi-stream job). I'd recommend opening a GitHub issue with your full logs for further investigation by the Airbyte team. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
j
For 1, we don’t get to “Executing finalization of table”…adding seperate logs:
Copy code
2026-04-01 12:35:56 destination INFO pool-4-thread-1 i.a.c.i.d.a.FlushWorkers(flush$lambda$6):135 Flush Worker (50721) -- Worker picked up work.
2026-04-01 12:35:56 destination INFO pool-4-thread-2 i.a.c.i.d.a.FlushWorkers(flush$lambda$6):135 Flush Worker (a199a) -- Worker picked up work....
2026-04-01 12:36:01 destination INFO pool-4-thread-2 i.a.c.i.d.a.s.GlobalAsyncStateManager(flushStates):207 Flushing states complete
2026-04-01 12:36:01 destination INFO pool-4-thread-2 i.a.c.i.d.a.GlobalMemoryManager(free):78 Freeing 297 bytes..
2026-04-01 12:36:01 destination INFO pool-4-thread-2 i.a.c.i.d.a.GlobalMemoryManager(free):78 Freeing 954835 bytes..
2026-04-01 12:36:01 destination INFO pool-4-thread-2 i.a.c.i.d.a.FlushWorkers(flush$lambda$6):170 Flush Worker (a199a) -- Worker finished flushing. Current queue size: 0
2026-04-01 12:36:01 destination INFO pool-4-thread-1 i.a.i.d.r.t.RedshiftDestinationHandler(execute):148 Sql cd8d6230-596a-4455-bf9f-7be5b7c6890f-d0f87745-6e6f-4939-830c-4ed8a27f8cc6 completed in 4558 ms
2026-04-01 12:36:01 destination INFO pool-4-thread-1 i.a.i.d.r.o.RedshiftStagingStorageOperation(writeToStage):136 Copy to target table airbyte_internal.test_schema_raw__stream_segment_7_airbyte_tmp in destination complete.
2026-04-01 12:36:01 destination INFO pool-4-thread-1 i.a.c.i.d.r.FileBuffer(deleteFile):75 Deleting tempFile data b115806f-476c-433e-9623-d736cf3e2ae613680151015727061375.csv.gz
2026-04-01 12:36:01 destination INFO pool-4-thread-1 i.a.c.i.d.a.s.GlobalAsyncStateManager(flushStates):153 Flushing states
2026-04-01 12:36:01 destination INFO pool-4-thread-1 i.a.c.i.d.a.s.GlobalAsyncStateManager(flushStates):207 Flushing states complete
2026-04-01 12:36:01 destination INFO pool-4-thread-1 i.a.c.i.d.a.GlobalMemoryManager(free):78 Freeing 0 bytes..
2026-04-01 12:36:01 destination INFO pool-4-thread-1 i.a.c.i.d.a.GlobalMemoryManager(free):78 Freeing 3740016 bytes..
...
2026-04-01 12:36:00 replication-orchestrator INFO Destination complete for Segment 6
2026-04-01 12:36:00 replication-orchestrator INFO Sending update for Segment 6 - RUNNING -> COMPLETE
2026-04-01 12:36:00 replication-orchestrator INFO Stream Status Update Received: Segment 6 - COMPLETE
2026-04-01 12:36:00 replication-orchestrator INFO Updating status: Segment 6 - COMPLETE
... no logs for status update on segment 7
026-04-01 12:51:03 destination INFO pool-5-thread-1 i.a.c.i.d.a.DetectStreamToFlush(getNextStreamToFlush):109 flushing: trigger info: test_schema - Segment  3, time trigger: true , size trigger: false current threshold b: 50 MB, queue size b: 0 bytes, penalty b: 0 bytes, after penalty b: 0 bytes
2026-04-01 12:51:04 destination INFO pool-5-thread-1 i.a.c.i.d.a.DetectStreamToFlush(getNextStreamToFlush):109 flushing: trigger info: test_schema - Segment 5, time trigger: true , size trigger: false current threshold b: 50 MB, queue size b: 0 bytes, penalty b: 0 bytes, after penalty b: 0 bytes
2026-04-01 12:51:04 destination INFO pool-4-thread-5 i.a.c.i.d.a.FlushWorkers(flush$lambda$6):135 Flush Worker (267f5) -- Worker picked up work.
2026-04-01 12:51:04 destination INFO pool-4-thread-3 i.a.c.i.d.a.FlushWorkers(flush$lambda$6):135 Flush Worker (3da31) -- Worker picked up work.
2026-04-01 12:51:04 destination INFO pool-4-thread-5 i.a.c.i.d.a.FlushWorkers(flush$lambda$6):141 Flush Worker (267f5) -- Attempting to read from queue namespace: test_schema, stream: Segment  3.
2026-04-01 12:51:04 destination INFO pool-4-thread-3 i.a.c.i.d.a.FlushWorkers(flush$lambda$6):141 Flush Worker (3da31) -- Attempting to read from queue namespace: test_schema, stream: Segment 5.
2026-04-01 12:51:04 destination INFO pool-4-thread-5 i.a.c.i.d.a.GlobalMemoryManager(free):78 Freeing 0 bytes..
2026-04-01 12:51:04 destination INFO pool-4-thread-3 i.a.c.i.d.a.GlobalMemoryManager(free):78 Freeing 0 bytes..
2026-04-01 12:51:04 destination INFO pool-4-thread-3 i.a.c.i.d.a.FlushWorkers(flush$lambda$6):159 Flush Worker (3da31) -- Batch contains: 0 records, 0 bytes bytes.
2026-04-01 12:51:04 destination INFO pool-4-thread-5 i.a.c.i.d.a.FlushWorkers(flush$lambda$6):159 Flush Worker (267f5) -- Batch contains: 0 records, 0 bytes bytes.
2026-04-01 12:51:04 destination WARN pool-4-thread-5 i.a.c.i.d.s.c.CsvSerializedBuffer(flushWriter):97 Trying to flush but no printer is initialized.
2026-04-01 12:51:04 destination WARN pool-4-thread-3 i.a.c.i.d.s.c.CsvSerializedBuffer(flushWriter):97 Trying to flush but no printer is initialized.
2026-04-01 12:51:04 destination WARN pool-4-thread-5 i.a.c.i.d.s.c.CsvSerializedBuffer(closeWriter):108 Trying to close but no printer is initialized.
2026-04-01 12:51:04 destination WARN pool-4-thread-3 i.a.c.i.d.s.c.CsvSerializedBuffer(closeWriter):108 Trying to close but no printer is initialized.
2026-04-01 12:51:04 destination INFO pool-4-thread-5 i.a.c.i.d.r.BaseSerializedBuffer(flush):166 Finished writing data to 142bcc09-c62d-4a4b-ae81-ed418c1e7e727276457147406708194.csv.gz (0 bytes)
2026-04-01 12:51:04 destination INFO pool-4-thread-3 i.a.c.i.d.r.BaseSerializedBuffer(flush):166 Finished writing data to b55914d5-8857-45d7-a407-feb33e9ec99110231438602933020383.csv.gz (0 bytes)
2026-04-01 12:51:04 destination INFO pool-4-thread-5 i.a.c.i.d.s.o.StagingStreamOperations(writeRecordsImpl):54 Buffer flush complete for stream Segment  3 (0 bytes) to staging
2026-04-01 12:51:04 destination INFO pool-4-thread-3 i.a.c.i.d.s.o.StagingStreamOperations(writeRecordsImpl):54 Buffer flush complete for stream Segment 5 (0 bytes) to staging
2026-04-01 12:51:04 destination INFO pool-4-thread-5 i.a.c.i.d.s.o.StagingStreamOperations(writeRecordsImpl):60 Skipping writing to storage since there are no bytes to write
2026-04-01 12:51:04 destination INFO pool-4-thread-3 i.a.c.i.d.s.o.StagingStreamOperations(writeRecordsImpl):60 Skipping writing to storage since there are no bytes to write
2026-04-01 12:51:04 destination INFO pool-4-thread-5 i.a.c.i.d.r.FileBuffer(deleteFile):75 Deleting tempFile data 142bcc09-c62d-4a4b-ae81-ed418c1e7e727276457147406708194.csv.gz
2026-04-01 12:51:04 destination INFO pool-4-thread-3 i.a.c.i.d.r.FileBuffer(deleteFile):75 Deleting tempFile data b55914d5-8857-45d7-a407-feb33e9ec99110231438602933020383.csv.gz
2026-04-01 12:51:04 destination INFO pool-4-thread-5 i.a.c.i.d.a.s.GlobalAsyncStateManager(flushStates):153 Flushing states
2026-04-01 12:51:04 destination INFO pool-4-thread-3 i.a.c.i.d.a.s.GlobalAsyncStateManager(flushStates):153 Flushing states
2026-04-01 12:51:04 destination INFO pool-4-thread-5 i.a.c.i.d.a.s.GlobalAsyncStateManager(flushStates):207 Flushing states complete
2026-04-01 12:51:04 destination INFO pool-4-thread-3 i.a.c.i.d.a.s.GlobalAsyncStateManager(flushStates):207 Flushing states complete
2026-04-01 12:51:04 destination INFO pool-4-thread-5 i.a.c.i.d.a.GlobalMemoryManager(free):78 Freeing 0 bytes..
2026-04-01 12:51:04 destination INFO pool-4-thread-3 i.a.c.i.d.a.GlobalMemoryManager(free):78 Freeing 0 bytes..
2026-04-01 12:51:04 destination INFO pool-4-thread-5 i.a.c.i.d.a.GlobalMemoryManager(free):78 Freeing 0 bytes..
2026-04-01 12:51:04 destination INFO pool-4-thread-3 i.a.c.i.d.a.GlobalMemoryManager(free):78 Freeing 0 bytes..
@kapa.ai Any other details based on above logs?
k
The user mentioned "logs in thread" in their original message, but no actual log content has been shared in this conversation for me to analyze directly. Based solely on what the knowledge sources contain, here are the most relevant additional details that may apply to your situation: Additional Details from Knowledge Sources Terminal status message never emitted for one stream in a multi-stream job The pattern you describe — all other streams complete successfully but one specific stream never gets marked complete — closely matches the 
TransientErrorException
bug documented across multiple connectors: > _"Input was fully read, but some streams did not receive a terminal stream status message... Streams without a status message: [stream_name]"_ This has been confirmed as a bug in the Bulk Load CDK's stream status handling, where the destination's load jobs complete successfully but the terminal 
COMPLETE
status is never received for that stream. [Streams without status message; BigQuery terminal status bug] Possible root causes identified by the Airbyte team: 1. The source not emitting a terminal status message after finishing the read for that specific stream. 2. The platform dropping or failing to forward the terminal status through the socket, especially under high message volumes. 3. Message loss in transit through the socket layer. [BigQuery terminal status bug] Why it works when run alone: This is consistent with the high-volume message loss theory — when the stream runs in isolation, there's less contention on the socket layer. If you can share the actual logs here, I'd be better positioned to help narrow it down further. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
j
@kapa.ai
Copy code
2026-04-01 12:35:56 destination INFO pool-4-thread-1 i.a.c.i.d.a.FlushWorkers(flush$lambda$6):135 Flush Worker (50721) -- Worker picked up work.
2026-04-01 12:35:56 destination INFO pool-4-thread-2 i.a.c.i.d.a.FlushWorkers(flush$lambda$6):135 Flush Worker (a199a) -- Worker picked up work....
2026-04-01 12:36:01 destination INFO pool-4-thread-2 i.a.c.i.d.a.s.GlobalAsyncStateManager(flushStates):207 Flushing states complete
2026-04-01 12:36:01 destination INFO pool-4-thread-2 i.a.c.i.d.a.GlobalMemoryManager(free):78 Freeing 297 bytes..
2026-04-01 12:36:01 destination INFO pool-4-thread-2 i.a.c.i.d.a.GlobalMemoryManager(free):78 Freeing 954835 bytes..
2026-04-01 12:36:01 destination INFO pool-4-thread-2 i.a.c.i.d.a.FlushWorkers(flush$lambda$6):170 Flush Worker (a199a) -- Worker finished flushing. Current queue size: 0
2026-04-01 12:36:01 destination INFO pool-4-thread-1 i.a.i.d.r.t.RedshiftDestinationHandler(execute):148 Sql cd8d6230-596a-4455-bf9f-7be5b7c6890f-d0f87745-6e6f-4939-830c-4ed8a27f8cc6 completed in 4558 ms
2026-04-01 12:36:01 destination INFO pool-4-thread-1 i.a.i.d.r.o.RedshiftStagingStorageOperation(writeToStage):136 Copy to target table airbyte_internal.test_schema_raw__stream_segment_7_airbyte_tmp in destination complete.
2026-04-01 12:36:01 destination INFO pool-4-thread-1 i.a.c.i.d.r.FileBuffer(deleteFile):75 Deleting tempFile data b115806f-476c-433e-9623-d736cf3e2ae613680151015727061375.csv.gz
2026-04-01 12:36:01 destination INFO pool-4-thread-1 i.a.c.i.d.a.s.GlobalAsyncStateManager(flushStates):153 Flushing states
2026-04-01 12:36:01 destination INFO pool-4-thread-1 i.a.c.i.d.a.s.GlobalAsyncStateManager(flushStates):207 Flushing states complete
2026-04-01 12:36:01 destination INFO pool-4-thread-1 i.a.c.i.d.a.GlobalMemoryManager(free):78 Freeing 0 bytes..
2026-04-01 12:36:01 destination INFO pool-4-thread-1 i.a.c.i.d.a.GlobalMemoryManager(free):78 Freeing 3740016 bytes..
...
2026-04-01 12:36:00 replication-orchestrator INFO Destination complete for Segment 6
2026-04-01 12:36:00 replication-orchestrator INFO Sending update for Segment 6 - RUNNING -> COMPLETE
2026-04-01 12:36:00 replication-orchestrator INFO Stream Status Update Received: Segment 6 - COMPLETE
2026-04-01 12:36:00 replication-orchestrator INFO Updating status: Segment 6 - COMPLETE
... no logs for status update on segment 7
026-04-01 12:51:03 destination INFO pool-5-thread-1 i.a.c.i.d.a.DetectStreamToFlush(getNextStreamToFlush):109 flushing: trigger info: test_schema - Segment  3, time trigger: true , size trigger: false current threshold b: 50 MB, queue size b: 0 bytes, penalty b: 0 bytes, after penalty b: 0 bytes
2026-04-01 12:51:04 destination INFO pool-5-thread-1 i.a.c.i.d.a.DetectStreamToFlush(getNextStreamToFlush):109 flushing: trigger info: test_schema - Segment 5, time trigger: true , size trigger: false current threshold b: 50 MB, queue size b: 0 bytes, penalty b: 0 bytes, after penalty b: 0 bytes
2026-04-01 12:51:04 destination INFO pool-4-thread-5 i.a.c.i.d.a.FlushWorkers(flush$lambda$6):135 Flush Worker (267f5) -- Worker picked up work.
2026-04-01 12:51:04 destination INFO pool-4-thread-3 i.a.c.i.d.a.FlushWorkers(flush$lambda$6):135 Flush Worker (3da31) -- Worker picked up work.
2026-04-01 12:51:04 destination INFO pool-4-thread-5 i.a.c.i.d.a.FlushWorkers(flush$lambda$6):141 Flush Worker (267f5) -- Attempting to read from queue namespace: test_schema, stream: Segment  3.
2026-04-01 12:51:04 destination INFO pool-4-thread-3 i.a.c.i.d.a.FlushWorkers(flush$lambda$6):141 Flush Worker (3da31) -- Attempting to read from queue namespace: test_schema, stream: Segment 5.
2026-04-01 12:51:04 destination INFO pool-4-thread-5 i.a.c.i.d.a.GlobalMemoryManager(free):78 Freeing 0 bytes..
2026-04-01 12:51:04 destination INFO pool-4-thread-3 i.a.c.i.d.a.GlobalMemoryManager(free):78 Freeing 0 bytes..
2026-04-01 12:51:04 destination INFO pool-4-thread-3 i.a.c.i.d.a.FlushWorkers(flush$lambda$6):159 Flush Worker (3da31) -- Batch contains: 0 records, 0 bytes bytes.
2026-04-01 12:51:04 destination INFO pool-4-thread-5 i.a.c.i.d.a.FlushWorkers(flush$lambda$6):159 Flush Worker (267f5) -- Batch contains: 0 records, 0 bytes bytes.
2026-04-01 12:51:04 destination WARN pool-4-thread-5 i.a.c.i.d.s.c.CsvSerializedBuffer(flushWriter):97 Trying to flush but no printer is initialized.
2026-04-01 12:51:04 destination WARN pool-4-thread-3 i.a.c.i.d.s.c.CsvSerializedBuffer(flushWriter):97 Trying to flush but no printer is initialized.
2026-04-01 12:51:04 destination WARN pool-4-thread-5 i.a.c.i.d.s.c.CsvSerializedBuffer(closeWriter):108 Trying to close but no printer is initialized.
2026-04-01 12:51:04 destination WARN pool-4-thread-3 i.a.c.i.d.s.c.CsvSerializedBuffer(closeWriter):108 Trying to close but no printer is initialized.
2026-04-01 12:51:04 destination INFO pool-4-thread-5 i.a.c.i.d.r.BaseSerializedBuffer(flush):166 Finished writing data to 142bcc09-c62d-4a4b-ae81-ed418c1e7e727276457147406708194.csv.gz (0 bytes)
2026-04-01 12:51:04 destination INFO pool-4-thread-3 i.a.c.i.d.r.BaseSerializedBuffer(flush):166 Finished writing data to b55914d5-8857-45d7-a407-feb33e9ec99110231438602933020383.csv.gz (0 bytes)
2026-04-01 12:51:04 destination INFO pool-4-thread-5 i.a.c.i.d.s.o.StagingStreamOperations(writeRecordsImpl):54 Buffer flush complete for stream Segment  3 (0 bytes) to staging
2026-04-01 12:51:04 destination INFO pool-4-thread-3 i.a.c.i.d.s.o.StagingStreamOperations(writeRecordsImpl):54 Buffer flush complete for stream Segment 5 (0 bytes) to staging
2026-04-01 12:51:04 destination INFO pool-4-thread-5 i.a.c.i.d.s.o.StagingStreamOperations(writeRecordsImpl):60 Skipping writing to storage since there are no bytes to write
2026-04-01 12:51:04 destination INFO pool-4-thread-3 i.a.c.i.d.s.o.StagingStreamOperations(writeRecordsImpl):60 Skipping writing to storage since there are no bytes to write
2026-04-01 12:51:04 destination INFO pool-4-thread-5 i.a.c.i.d.r.FileBuffer(deleteFile):75 Deleting tempFile data 142bcc09-c62d-4a4b-ae81-ed418c1e7e727276457147406708194.csv.gz
2026-04-01 12:51:04 destination INFO pool-4-thread-3 i.a.c.i.d.r.FileBuffer(deleteFile):75 Deleting tempFile data b55914d5-8857-45d7-a407-feb33e9ec99110231438602933020383.csv.gz
2026-04-01 12:51:04 destination INFO pool-4-thread-5 i.a.c.i.d.a.s.GlobalAsyncStateManager(flushStates):153 Flushing states
2026-04-01 12:51:04 destination INFO pool-4-thread-3 i.a.c.i.d.a.s.GlobalAsyncStateManager(flushStates):153 Flushing states
2026-04-01 12:51:04 destination INFO pool-4-thread-5 i.a.c.i.d.a.s.GlobalAsyncStateManager(flushStates):207 Flushing states complete
2026-04-01 12:51:04 destination INFO pool-4-thread-3 i.a.c.i.d.a.s.GlobalAsyncStateManager(flushStates):207 Flushing states complete
2026-04-01 12:51:04 destination INFO pool-4-thread-5 i.a.c.i.d.a.GlobalMemoryManager(free):78 Freeing 0 bytes..
2026-04-01 12:51:04 destination INFO pool-4-thread-3 i.a.c.i.d.a.GlobalMemoryManager(free):78 Freeing 0 bytes..
2026-04-01 12:51:04 destination INFO pool-4-thread-5 i.a.c.i.d.a.GlobalMemoryManager(free):78 Freeing 0 bytes..
2026-04-01 12:51:04 destination INFO pool-4-thread-3 i.a.c.i.d.a.GlobalMemoryManager(free):78 Freeing 0 bytes..
k
Looking at your logs, here's what they reveal: What the Logs Show Segment 7 successfully written to staging:
Copy code
Copy to target table airbyte_internal.test_schema_raw__stream_segment_7_airbyte_tmp in destination complete.
The temp table write for Segment 7 completes successfully at 
12:36:01
. Segment 6 gets marked complete, Segment 7 does not:
Copy code
replication-orchestrator INFO Destination complete for Segment 6
replication-orchestrator INFO Sending update for Segment 6 - RUNNING -> COMPLETE
... no logs for status update on segment 7
After ~15 minutes, the destination is still looping on empty flushes for other streams (Segment 3, 5): • 
time trigger: true
, 
size trigger: false
, 
queue size b: 0 bytes
• 
Batch contains: 0 records, 0 bytes
• 
Skipping writing to storage since there are no bytes to write
Analysis The destination successfully wrote Segment 7's data to the temp table, but the replication orchestrator never received a terminal status update for it. The destination then enters a loop flushing empty batches for other streams on a time trigger, waiting indefinitely. This matches the known pattern where the source or platform fails to emit a terminal stream status message for a specific stream, causing the destination to hang. The destination has done its job (data is in the temp table), but without the terminal status signal, it cannot finalize and the orchestrator stays stuck. [Streams without status message; BigQuery terminal status bug] Key Observations 1. The issue is not a destination write failure — the data was written successfully. 2. The hang occurs specifically at the status signaling layer, not the data layer. 3. The empty flush loops (
0 bytes
, 
0 records
) suggest the destination is idle and waiting, not actively processing. The knowledge sources don't contain enough detail about your specific Redshift destination version (v3.5.4) or this exact code path to pinpoint the root cause further. Given this is an older-style async destination (using 
FlushWorkers
, 
GlobalAsyncStateManager
), it may be a different code path than the newer Bulk Load CDK issues documented in the GitHub issues. I'd recommend opening a GitHub issue with these logs for the Airbyte team to investigate. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
j
Hubspot was a typo - the source connector was custom using 
source-declarative-manifest
@kapa.ai would that impact analysis?
k
Yes, that significantly changes the analysis and actually makes the root cause much clearer. Updated Analysis Your source is 
source-declarative-manifest
, which has a confirmed, documented bug where it fails to emit terminal stream status messages required by modern destinations. This is directly relevant to your hang on Segment 7. From the GitHub issue: > "The connector reads all data successfully (authentication works, pagination works, records are read), but does not emit the terminal stream status message that destinations with CDK v3 require." [Streams without status message] This explains exactly what your logs show: • Segment 7's data was successfully written to the temp table ✅ • The replication orchestrator never received a terminal status update for Segment 7 ❌ • The destination looped indefinitely waiting for a signal that never came Why It Works When Run Alone The knowledge sources don't explicitly explain this, but the documented bug notes that the issue affects streams inconsistently — it has caused major outages and has been observed even with small datasets (~170 records), so volume alone doesn't explain it. [Streams without status message] Current Status of the Bug • This issue was marked P1 priority by the Airbyte team. • A previous fix in June 2025 was only a temporary revert — the permanent fix was never implemented. • The bug was still present in 
source-declarative-manifest:7.7.1
as of February 2026. [Streams without status message] I'd recommend referencing GitHub issue #72367 when filing your support ticket, as your logs are strong evidence of the same underlying bug. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
j
Can I change the version of source-declarative-manifest? Which version would not have this bug? @kapa.ai
k
Based on the knowledge sources available, I can partially address this: Changing source-declarative-manifest Version On Helm/OSS deployments, there is a known complication with upgrading or pinning the version of 
source-declarative-manifest
. From the forum discussion: > "Is there a clean way to upgrade 
source-declarative-manifest
without it getting blown away by upgrades via Helm? It's odd to me that they would be out of sync in a virgin deployment to start with." The Airbyte team acknowledged this as a known pain point and noted that Helm should not have the "last word" on what connector versions run, but a clean solution was still being worked on at the time. [Connector Builder/Low Code] Which Version Fixes the Bug? Unfortunately, the knowledge sources do not identify a specific version of 
source-declarative-manifest
that resolves this issue. What is documented is: • The bug was present in v7.6.5 (Airbyte Cloud, June 2025 incident) • The bug was still present in v7.7.1 as of February 2026 • The June 2025 fix was only a temporary revert, and the permanent fix was never confirmed as implemented [Streams without status message] There is no information in the knowledge sources about a specific "safe" version to downgrade to that avoids this bug. I'd recommend checking GitHub issue #72367 directly for the latest status, as the Airbyte oncall team was actively tracking it there. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
j
@kapa.ai I’m on version 7.0.4 - does that track?
k
Based on the knowledge sources available, I cannot confirm whether version 7.0.4 of 
source-declarative-manifest
is affected or unaffected by this bug. What the knowledge sources do document is: • The bug was confirmed present in v7.6.5 and v7.7.1 [Streams without status message] • No "safe" version is identified, and no lower bound is mentioned Since v7.0.4 is older than the versions documented as affected, it's possible the bug was introduced in a version between 7.0.4 and 7.6.5 — but the knowledge sources don't contain enough information to confirm that. I'd recommend checking GitHub issue #72367 directly, as the Airbyte team may have more detail on when the regression was introduced. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
j
What is the lowest version of source-declarative-manifest compatible with airbyte 2?
@kapa.ai What is the lowest version of source-declarative-manifest compatible with airbyte 2?
k
The knowledge sources do not contain information about the minimum version of 
source-declarative-manifest
required for compatibility with Airbyte 2.x. What the sources do note is that starting with v0.2.1 of certain connectors (e.g., Smaily, Tempo, Secoda), the Docker image became rootless and is not compatible with Airbyte versions earlier than 0.64 [Smaily changelog; Tempo changelog] — but this refers to individual source connectors, not 
source-declarative-manifest
itself, and doesn't address Airbyte 2.x compatibility specifically. For a definitive answer on the minimum compatible version of 
source-declarative-manifest
with Airbyte 2, I'd recommend checking the Airbyte documentation or the GitHub repository directly. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
j
@kapa.ai Which destinations use CDK v3? Does redshift fall under that?
k
Based on the knowledge sources available, the only destination explicitly mentioned as using CDK v3 is BigQuery (specifically 
destination-bigquery:3.0.16
), in the context of the terminal stream status message bug. [Streams without status message] Redshift is not described as using CDK v3 in the knowledge sources. The Redshift destination changelog shows it uses the Java/Kotlin CDK (e.g., CDK 0.23.x, 0.28.x, 0.33.x, 0.35.x), which is a different CDK lineage from the Python CDK v3 referenced in the BigQuery/declarative-manifest context. [Redshift Changelog] This is actually relevant to your situation: the terminal stream status message bug documented in GitHub issue #72367 was specifically framed around CDK v3 destinations (like BigQuery). However, your logs show the same symptom occurring with Redshift — suggesting either: 1. The issue in your case has a different but related root cause, or 2. The 
source-declarative-manifest
bug affects a broader set of destinations than just CDK v3 ones. The knowledge sources don't contain enough detail to confirm which of these applies to your specific setup. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
2 Views
Open in Slack
PreviousNext
Powered by