Airbyte #replication-troubleshooting

Mehmet Akif Magol

05/08/2026, 9:55 PM

Hi all 👋 Looking for advice on intermittent missing rows with Incremental | Append + Deduped on a SQL Server → Snowflake pipeline. Setup: • Airbyte OSS deployed on AKS via Helm • Source:

airbyte/source-mssql:4.1.22

• Destination:

airbyte/destination-snowflake:3.15.4

• Sync mode: Incremental | Append + Deduped • Frequency: every 15 minutes • Cursor field:

UpdatedDateTime

(SQL Server

DATETIME

, ~3.33 ms precision, stored in UTC) • Primary key:

Id

(BIGINT IDENTITY) • Both SQL Server

UpdatedDateTime

and the Airbyte cluster are UTC, no timezone mismatch Problem: Most rows sync correctly, but occasionally rows are missed entirely — sometimes by 2+ days. The source

UpdatedDateTime

shows the row was updated, but Snowflake (both raw and final tables) never received the new version. Sync jobs themselves complete with

failures: [ ]

and no errors. The cursor advances normally. What I've ruled out: • Not a sync failure — jobs succeed cleanly • Not a timezone issue — both sides are UTC • Not the

UpdatedDateTime

not being maintained — confirmed updated values exist in source • Not a dedup problem — checked the raw table, the new row version was never extracted Hypothesis: Classic transaction visibility skew — long-running transactions stamp

UpdatedDateTime

at UPDATE time but commit later, after the cursor has already advanced past that timestamp. The row becomes permanently invisible to incremental sync because

UpdatedDateTime <= cursor

on subsequent runs. Constraints: • Can't enable CDC right now (need DBA coordination + change window) • Looking for a lookback / overlap window approach but don't see a native option in source-mssql Questions: 1. Has anyone hit this with

source-mssql

DATETIME

cursor? Was transaction commit skew the actual cause? 2. Is there a supported way to configure a cursor lookback window I'm missing? 3. For those who've gone the cursor-rewind route (modifying the

state

table directly), any gotchas with recent Airbyte versions? 4. Any other proven mitigations short of CDC? Thanks in advance 🙏

abdalrahman bebars

05/11/2026, 11:02 AM

I use the Community edition self-hosted version and chart 2.0.18 I have a problem with job resources configuration, as I need to run multiple connections concurrently But each job requests 1 vCPU and 6 GiB RAM, which is too much for my cluster Is there any way to configure the resources requested by the jobs? I tried the Jobs field in Helm values, but it led to nothing, as it didn't apply to the requested resources I tried the workloads also, but it changed nothing What should I do in that case?

Diana Kot

05/13/2026, 8:29 AM

Hi All! Is anyone using Apple Search Ads Connector? I'm not able to synchronize it for the past 10 days. It runs for ages and eventually fails, although I'm trying to fetch only 1 report - apple search ads keywords daily. Do you guys have similar issues? Anyone knows how to handle it? Thank you in advance for the tips!

Thomas

05/13/2026, 9:55 AM

Hi there, I'm trying to install Airbyte on AWS EC2

t4g.xlarge

using :

abctl local install --host <http://data-airbyte.acme.fr|data-airbyte.acme.fr> --insecure-cookies --no-browser

CLI OK without error :

Copy code

SUCCESS  Installed Helm Chart airbyte/airbyte:
            Name: airbyte-abctl
            Namespace: airbyte-abctl
            Version: 2.1.0
            AppVersion: 2.1.0
            Release: 1
  INFO    Starting Helm Chart installation of 'nginx/ingress-nginx' (version: 4.15.1)
 SUCCESS  Installed Helm Chart nginx/ingress-nginx:
            Name: ingress-nginx
            Namespace: ingress-nginx
            Version: 4.15.1
            AppVersion: 1.15.1
            Release: 1
  INFO    No existing Ingress found, creating one
 SUCCESS  Ingress created
 SUCCESS  Launching web-browser disabled. Airbyte should be accessible at
            <http://localhost:8000>
 SUCCESS  Airbyte installation complete.
            A password may be required to login. The password can by found by running
            the command abctl local credentials

Using Firefox, when navigating to

<http://data-airbyte.acme.com>

I'm using password from

abctl local credentials

to be authenticated using HTTP Basic Auth (no username). Not sure that is related, but I can see one HTTP error : POST http://data-airbyte.acme.com:8000/api/oauth/access_token

Copy code

{
  "error_description": "refresh_token and grant_type are required",
  "error": "invalid_request"
}

Of course, port 8000 is open to EC2 instance. Do you have any clue ?

Austin Fay

05/13/2026, 4:27 PM

Hi 👋 This is not replication related, but I didn't know where else to put this. This has to do with the Terraform provider. I posted the following issue on Github a couple weeks ago as a request to apply a patch to version 1.0 of the provider that had been applied to version 1.1. The issue is that 1.0 is used as a "bridge" to migrate Terraform state to the new format used in versions 1.1 and above, and without a fix to the bug in that version, I can't migrate my Terraform state to the new 1.1 format. Unfortunately, I haven't gotten any responses on that issue. At this point, I'm just looking for a solution for migrating my pre-1.0 Terraform state to the new 1.1 format. Is there a recommended way I should go about doing this? https://github.com/airbytehq/terraform-provider-airbyte/issues/431

Prem Kumar

05/18/2026, 9:14 AM

Hi there, I'm running a sync to a Databricks destination, but the process seems to be crashing/hanging right in the middle of a SQL execution. I suspect it might be an OOM (Out of Memory) issue. The logs show that the replication pod is requesting 4Gi for each container (source, destination, and orchestrator): Plaintext

Copy code

2026-05-18 14:00:02 platform INFO [source] image: airbyte/source-file:0.6.0 resources: ResourceRequirements(limits={memory=4Gi, cpu=4}, requests={memory=1Gi, cpu=1})
2026-05-18 14:00:02 platform INFO [destination] image: airbyte/destination-databricks:3.3.8 resources: ResourceRequirements(limits={memory=4Gi, cpu=4}, requests={memory=1Gi, cpu=1})

The sync starts fine, but as soon as it begins the

CREATE TABLE

and JDBC operations, the logs just cut off: Plaintext

Copy code

2026-05-18 14:00:31 destination INFO sync-operations-1 ... default.test-new-file: non-truncate sync. Creating raw table if not exists.
2026-05-18 14:00:31 destination INFO sync-operations-1 ... Executing sql ... [CREATE TABLE IF NOT EXISTS airbyte_catalog.vanij.default_raw__stream_test_new_file ...
2026-05-18 14:00:32 destination INFO sync-operations-1 i.a.c.d.j.JdbcDatabase(execute$la...

I checked the previous connection checks and they passed, so the credentials are correct. It only seems to die when the actual data movement/table creation starts. Is there a way to verify if this is an OOM kill on the pod? Any help would be appreciated!

test____test_db_logs_43_txt.txt

john roger

05/20/2026, 1:50 PM

Hi Airbyte community — I’m running Airbyte v2 OSS in a fully air-gapped environment and hitting a 500 Internal Server Error on the connector documentation endpoint. In the browser console, the UI fails while loading destinations and shows connector_documentation/get errors, with repeated 500 responses . I’m using a VPN-configured machine with Chrome on the same machine, and I’m trying to connect from there. Once the VPN is connected, there is no internet access on that machine, so Airbyte appears unable to fetch remote connector documentation/definitions . Has anyone successfully run Airbyte v2 OSS in a true air-gapped setup and resolved this? If yes, what was the workaround — image mirroring only, config change, patching the web app/backend, or a specific version upgrade?

Passarelli

05/23/2026, 2:57 PM

Hey everyone, I've been struggling with a CDC issue. Error:

Saved offset is before replication slot's confirmed lsn. Please reset the connection, and then increase WAL retention and/or increase sync frequency to prevent this from happening in the future.

Connector:`source-postgres:3.6.35` Setup: Self-hosted Airbyte on Kubernetes → RDS PostgreSQL (CDC via pgoutput) → S3 We have already tried: - Increasing WAL retention to 10 GB. Our peak data volume between syncs is only ~3 GB, so WAL exhaustion was never the real cause - Increased sync frequency to every 1 hour. Didn't help - Set

invalid_cdc_cursor_position_behavior

Re-sync data

— this silently masked the error by triggering full refreshes on every failure I am aware that this is a common error among the community. Has anyone manage to find a proper solution? 🙏

guifesquet

05/29/2026, 3:29 PM

hi, does anyone has this error while creating a connection

The source or destination used in this connection does not support file transfers, so they cannot be enabled.

Emon Datta

06/03/2026, 5:00 AM

hi all, I had a question about expected behavior for BigQuery Incremental Syncs (Append + Deduped) with non-granular cursors. Question: I'm syncing a BigQuery table to a snowflake table. We have a primary key and cursor on a large BigQuery table so we are using the Incremental - Append + Deduped option. If we have new rows that are added (or modified) after a sync runs, which have the same cursor value as the previous max cursor value, will they still be processed on the next sync run? Example: For example, let's say we have 1 row where the cursor indicates the updated_at is "June 3 2026 at 1 am", and the sync runs with that as the max cursor values. After the sync runs, 6 additional rows (perhaps some net-new rows, and some updated rows of existing data) now have the same updated_at as "June 3 2026 at 1 am". Would all those 6 additional rows still be processed on the next sync run? Context: I'm having trouble understanding what the expectation is for this scenario is, since the documentation mentions the cursor query logic being

select * from table where cursor_field > 'last_sync_max_cursor_field_value'

which implies that those 6 rows would NOT be processed since their cursor value is NOT > 'last_sync_max_cursor_field_value'. However, the Inclusive Cursors section of the documentation seems to suggest that these rows would indeed be processed. Which is correct?

Jitendra Singh Bisht

06/08/2026, 12:20 PM

Hey folks! 👋 We're hitting a Terraform provider bug when trying to create an airbyte_source_custom, airbyte_destination_custom, and airbyte_connection (with multiple streams) in a single terraform apply.

Error: Provider produced invalid plan

Provider "<http://registry.terraform.io/airbytehq/airbyte|registry.terraform.io/airbytehq/airbyte>" planned an invalid value

for airbyte_connection.oracle_fusion_fscm_databricks_sync.configurations.streams:

count in plan (cty.UnknownVal(cty.Number)) disagrees with count in config

(cty.NumberIntVal(5)).

This is a bug in the provider, which should be reported in the provider's

own issue tracker.

Provider version: airbytehq/airbyte ~> 0.13.0 Terraform version: hashicorp/terraform v1.x What we're doing:

Copy code

resource "airbyte_connection" "oracle_fusion_fscm_databricks_sync" {
  name           = "DIP-OracleFusionFSCM-Databricks-Sync"
  source_id      = airbyte_source_custom.oracle_fusion_fscm_source.source_id
  destination_id = airbyte_destination_custom.oracle_fusion_fscm_destination.destination_id
  configurations = {
    streams = [
      { name = "stream_1", sync_mode = "incremental_deduped_history", ... },
      { name = "stream_2", sync_mode = "incremental_deduped_history", ... },
      { name = "stream_3", sync_mode = "incremental_deduped_history", ... },
      { name = "stream_4", sync_mode = "incremental_deduped_history", ... },
      { name = "stream_5", sync_mode = "incremental_deduped_history", ... },
    ]
  }
}

Observations: 1. ✅ Works fine with 1 stream in the connection 2. ❌ Fails with 5 streams — count in plan (UnknownVal) disagrees with count in config (5) 3. ✅ Works fine with 5 streams if source already exists in state (i.e. only connection is being created) 4. The issue only occurs on first-time creation when source_id is (known after apply) Root cause hypothesis: When source_id is unknown at plan time, the provider tries to validate the stream count against the source's catalog but gets UnknownVal — this only manifests with N>1 streams. Questions: 1. Is this a known issue in airbytehq/airbyte provider v0.13.0? 2. Is there a workaround to create source + connection with multiple streams in a single apply?

Amal Mokhtar

06/10/2026, 10:38 AM

Hi all, running into a persistent CDC issue with

source-postgres:3.7.2

and hoping someone has seen this. Problem: After a full refresh completes successfully, the very next incremental CDC sync loads 0 records, and this repeats every time. Root cause (probably): The full refresh does the ctid snapshot correctly but saves the initial WAL LSN as its final state (the LSN at snapshot start, not at snapshot end). So on the next incremental run,

confirmed_flush_lsn == saved_offset_lsn

, Debezium sees itself as caught up, skips the snapshot, streams only heartbeats, and exits with 0 records. All WAL changes between snapshot start and the next sync run are lost. This seems related to

flush.lsn.source = false

, the slot LSN never advances during the ctid load so the saved state never moves forward. Question: Is this a known bug in 3.7.x? Is there a patched version or a recommended workaround short of doing a manual refresh every day? @kapa.ai

Wu Ricky

06/12/2026, 1:20 AM

How to resolve connection is always spinning? I use Google Sheet as source and PostgreSQL as destination. The version of Airbyte is 2.1 . sample log: 2026-06-12 052014 platform INFO Transitioning workload to running state 2026-06-12 052014 platform INFO ----- START DISCOVER ----- 2026-06-12 052014 platform INFO 2026-06-12 052014 platform INFO Workload successfully transitioned to running state @kapa.ai

Nevo

06/14/2026, 6:15 AM

Hi all, over the past couple of days I'm experiencing some issues with the PayPal source connector, when trying to get transactions data. My stream is set to incremental append. The error message is as follow:

Copy code

'GET' request to '<https://api-m.paypal.com/v1/reporting/transactions?fields=all&page_size=500&start_date=2026-06-11T21%3A49%3A26Z&end_date=2026-06-12T00%3A33%3A17Z>' failed with status code '404' and error message: 'Data for the given start date is not available.'. Request (body): 'None'. Response (body): '{'name': 'INVALID_REQUEST', 'message': 'Data for the given start date is not available.', 'debug_id'...

Connector version: 2.6.31 Does anyone else encountered this? any suggestions? @kapa.ai

Damir

06/14/2026, 7:20 PM

Hi 👋 Airbyte creates partitioned tables in BigQuery destinations. This is a bad practice as transactional tables most often are not big enough to benefit from partioning. Is it possible to turn this thing off?

Nisheet Das

06/23/2026, 9:18 PM

Hi! We are using Airbyte for data replication but facing some issues with one of our pipelines (it has a lot of data yes). I see failure logs on Airbyte saying this:

Copy code

2026-06-22 21:36:18 destination ERROR com.google.cloud.bigquery.BigQueryException: 400 Bad Request
2026-06-22 21:36:18 destination ERROR PUT <https://bigquery.googleapis.com/upload/bigquery/v2/projects/XXXXXXXXXXXXXXXXXX/jobs?uploadType=resumable&upload_id=XXXXXXXXXXXXXXXXXX>
2026-06-22 21:36:18 destination ERROR {
2026-06-22 21:36:18 destination ERROR   "error": {
2026-06-22 21:36:18 destination ERROR     "code": 400,
2026-06-22 21:36:18 destination ERROR     "message": "Request had invalid euc header.",
2026-06-22 21:36:18 destination ERROR     "errors": [
2026-06-22 21:36:18 destination ERROR       {
2026-06-22 21:36:18 destination ERROR         "message": "Request had invalid euc header.",
2026-06-22 21:36:18 destination ERROR         "domain":"**********",
2026-06-22 21:36:18 destination ERROR         "reason": "invalid"
2026-06-22 21:36:18 destination ERROR       }
2026-06-22 21:36:18 destination ERROR     ],
2026-06-22 21:36:18 destination ERROR     "status": "INVALID_ARGUMENT"
2026-06-22 21:36:18 destination ERROR   }
2026-06-22 21:36:18 destination ERROR }

Anyone else faced this before? Any workarounds?

Assaf Fraindlich

06/24/2026, 6:47 AM

Hi, i'm trying to connect Netsuite community connector. I went through the entire documentation on this and defined everything mentioned there. When trying to set up the connection - the testing fails on this error: Configuration check failed HTTPError('400 Client Error: Bad Request for url: https://xxxxxxx.suitetalk.api.netsuite.com/services/rest/record/v1/contact?limit=1') any ideas? all of the below has been verified: 1. Verify REST Web Services is enabled Go to Setup » Company » Enable Features » SuiteCloud tab Scroll to SuiteTalk (Web Services) and ensure REST WEB SERVICES is checked Also confirm CLIENT SUITESCRIPT, SERVER SUITESCRIPT, and TOKEN-BASED AUTHENTICATION are enabled 2. Verify your role has permissions to access Contact records Go to Setup » Users/Roles » Manage Roles and edit the role assigned to your integration Under the Permissions tab, ensure the Lists section includes the Contacts permission with at least View access Also confirm that Transactions, Reports, Lists, and Setup sections all have the required permissions as described in the setup guide 3. Check your Realm (Account ID) format The Realm should be your Account ID (e.g., 5319463 for production, or 5319463_SB2 for sandbox) You can verify this under Setup » Company » Company Information 4. Verify the integration record is active Go to Setup » Integration » Manage Integrations Ensure the integration you created has State set to Enabled 5. Try specifying object types If the default Contact check keeps failing, try adding specific object types in the connector configuration to test with a different record type that your role definitely has access to

Fabrizio Spini

06/24/2026, 12:38 PM

Hi everyone 👋 We've been debugging a silent CDC failure on Airbyte 2.1.0 (self-hosted, GKE) and found what looks like a platform bug. Sharing here in case others are affected or someone knows of a fix. 🐛 Bug: nightly discover resets CDC state by updating
sourceCatalogId
even on empty schema diff Setup • Airbyte 2.1.0, self-hosted on GKE •

source-mysql:3.51.5

(CDC mode,

invalid_cdc_cursor_position_behavior: Fail sync

) •

destination-bigquery:3.0.16

•

nonBreakingChangesPreference: ignore

What happens Every night at midnight UTC a scheduled discover runs. When it completes,

ConnectionsHandler.applySchemaChange()

updates the connection's

sourceCatalogId

— even when the schema diff is empty. New syncs launched under the new

catalogId

find no associated CDC state and fall back to an old saved binlog position. The result is a silent, growing backlog: each sync reprocesses an ever-increasing number of records from the old binlog position. In our case this grew from ~2M to ~55M records over 2 days before BigQuery started returning 500s and the sync loop became permanent. Why
nonBreakingChangesPreference: ignore
doesn't help This setting controls stream-level propagation, but

applySchemaChange()

still updates

sourceCatalogId

on every discover completion regardless. The CDC state orphaning happens upstream of that logic. Impact • Pipeline silently accumulates backlog for days without alerting • Failure only surfaces when destination (BigQuery) starts rejecting large batch inserts • By then the binlog position in the CDC state may no longer exist (rotated out) Question Is this a known issue? Is there a way to prevent

sourceCatalogId

from being updated when there's no actual schema change? We couldn't find a config option that controls this behavior. Current mitigation We deployed a Cloud Run job (hourly) that queries sync stats and alerts on Slack if any CDC connection shows 5 consecutive runs with monotonically increasing records emitted where the latest run processes >2x the records of the oldest in the window. This lets us catch the backlog early before volumes become critical. Thanks 🙏

👀 1

ranjeetkumar.singh

06/26/2026, 9:46 PM

Hi, We are using open source airbyte and running on linux. Full Refresh Overwrite sync is not doing full overwrite of table, instead we see data get duplicated. Source is SQL Server with no CDC enabled. There is no specific error in log indicate any issue . In status, it show accurate row count of source being loaded but in destination, row count is significantly higher than that indicating that data is not getting overwritten but added. Has anyone faced this issue?

contact966

06/28/2026, 8:45 AM

Hi everyone, I'm trying to configure HashiCorp Vault (tested with both Vault 1.13 and OpenBao 2.5.5) as an external secret manager with Airbyte Core 2.1.0 installed via abctl. Config in values.yaml: global: secretsManager: type: VAULT vault: address: "http//<vault host>8200" prefix: "airbyte" VAULT_AUTH_TOKEN is correctly set in the Kubernetes secret

airbyte-abctl-airbyte-secrets

and confirmed present in the server and workload-launcher pods. Observed behavior: When creating a destination connector (postgreSQL) and running a check, the ephemeral pod fails with: SecretCoordinateException: That secret was not found in the store! Coordinate: airbyte_workspace_00000000-..._secret_<uuid>_v1 Vault returns a 403 on read. The secret was never written to Vault in the first place — the server doesn't seem to write connector secrets to Vault when saving a connection. Question: Is writing connector secrets to Vault actually supported in Airbyte Core 2.x? The documentation is unclear on this point. Thanks!

Manish Pandey

06/30/2026, 10:03 AM

Hello, We are using the open-source version of Airbyte deployed on a Linux server in GCP. On 23 June 2026, Airbyte suddenly went down. We upgraded Airbyte to the latest available version, but the sync jobs were still not working after the upgrade. As a next step, we performed a fresh installation of Airbyte, after which the sync jobs started working successfully. Has anyone experienced a similar issue or faced the same behavior with Airbyte? Any insights on the possible root cause or recommendations would be appreciated.

gacosta

07/01/2026, 7:04 PM

Hi, I have opensource airbyte deployed on an EC2 instance (type t3.xlarge with 4 CPUs and 16 GiB in mem). When I first installed abctl and tried running a replication instance for CDC (postgres to snowflake) I got the following error ERROR Stage Pipeline Exception: io.airbyte.workload.launcher.pipeline.stages.model.StageError: io.airbyte.workers.exception.ResourceConstraintException: Unable to start the REPLICATION pod. This may be due to insufficient system resources. Please check available resources and try again. message: io.airbyte.workers.exception.ResourceConstraintException: Unable to start the REPLICATION pod. This may be due to insufficient system resources. Please check available resources and try again. stackTrace: [Ljava.lang.StackTraceElement;@7447b01e I then re-installed abctl on low resource mode and that worked, but the sync times after the initial loads on my connections have been quite slow. So my question are 1) Would running this not on low resource mode improve those sync times? 2) What size EC2 instance is recommended to allow the replication pod to have enough resources to start?

kodanda ramudu

07/02/2026, 5:14 PM

Hello, TLDR; I have fresh deployment of Airbyte2.0.18 on Azure AKS cluster. It is up and running but when I try to create source connection it is throwing 502 error. Does anyone know how to resolve it ? looking for help with Airbyte 2.0.1 on Kubernetes (Helm chart 2.0.18). Saving/testing any source (e.g. MySQL) fails with: UI: Failed to save … errors.http.badGateway / Airbyte is temporarily unavailable (HTTP 502) No connector check pods are created Environment Helm chart: 2.0.18 (Artifactory mirror of airbyte chart) Platform: 2.0.1 (airbyte/workload-launcher:2.0.1) Edition: community Deployment: AKS, single namespace (hybrid CP+DP) DB: external Azure PostgreSQL Storage: Azure Blob (STORAGE_TYPE=azure, connection string via K8s secret / ExternalSecrets) Auth: global.auth.enabled: true Ingress → airbyte-server on :8001 What works UI loads, server/temporal/worker/workload-api-server pods healthy (after fixing temporal.database.engine → postgres12) ExternalSecrets synced; AZURE_STORAGE_CONNECTION_STRING set on launcher Blob containers exist (airbyte-v2-state, airbyte-v2-workloadoutput, airbyte-v2-logs) Network from launcher pod to storage: curl to *.blob.core.windows.net connects (TLS OK) Dataplane routing OK: workspace + workload dataplane_group_id match launcher ApiQueuePoller UUID; dataplane enabled=true Workload-launcher polls queue successfully: POST /api/v1/workload/queue/poll → 200 What fails On source test, workload row stays pending → later failure with termination_reason: "The workload was never claimed" and dataplane_id NULL Launcher log shows dequeue + APPLY Stage: BUILD for *_check workload, then no LAUNCH, no check pod After BUILD starts, Azure SDK logs Netty client + version mismatch warning: azure-netty 4.1.118.Final vs classpath Netty 4.2.4.Final HTTP pool created for stairbytedveu1.blob.core.windows.net:443, then silence (no LAUNCH, no exception in grep window) WLAS logs during test show worker GET /api/v1/workload/{id}_check (200) but no launcher claim traffic in that window (launcher seems stuck in BUILD before claim completes) Config notes workloadLauncher.hpa.enabled: false, replicaCount: 1 WORKLOAD_LAUNCHER_ENABLED_NAMESPACES set to same namespace as JOB_KUBE_NAMESPACE WORKLOAD_API_AUTH_HEADER + WORKLOAD_API_BEARER_TOKEN (jwt secret) on worker + workloadApiServer + workloadLauncher Tried JAVA_TOOL_OPTIONS=-Dio.netty.transport.noNative=true on launcher — BUILD still hangs Questions Is BUILD hanging on Azure Blob with Netty version mismatch a known issue on 2.0.1 / chart 2.0.18? Recommended fix (image/chart version, JVM flags)? Should WORKLOAD_API_BEARER_TOKEN on workload-launcher be set manually when auth.enabled=true, or does chart wire internal JWT only? Any required Helm values for Azure storage + workload-launcher BUILD we might be missing? Related issues we’ve seen: #68115, #70451, #74275 — our case looks like poll works but BUILD never reaches LAUNCH. Happy to share redacted launcher logs (BUILD → blob pool) and workload table rows if helpful. Thanks!

Rakim

07/03/2026, 11:20 AM

Hey team. wondering if you could help with this issue. Here is the ai chat i perviously had Subject: abctl v0.30.4 + Airbyte 2.1.0 —
--low-resource-mode
toggle breaks install, MinIO missing Environment: • Airbyte: 2.1.0 (self-hosted, single-node kind on EC2) • abctl: v0.30.4 • Helm chart: V2 (default) What happened: Originally installed without

--low-resource-mode

, then re-ran with the flag. This triggered a known Helm patch ordering bug (duplicate

..._REQUEST

entries with both

value:0

and

valueFrom

in the configmap patch list). Now every

abctl local install

— with or without the flag — fails at ~23s before pods start. Error:

Copy code

unable to install helm: failed to create patch: The order in patch list:
[map[name:CHECK_JOB_MAIN_CONTAINER_CPU_REQUEST value:0] ... map[name:CHECK_JOB_MAIN_CONTAINER_MEMORY_REQUEST valueFrom:...]]
doesn't match $setElementOrder list: [...]

What's been tried: • Re-running install with/without

--low-resource-mode

— same error • Deleting the cron deployment — fails earlier at the configmap patch •

--chart-version=1.7.2

— not viable, V1 chart is incompatible with Airbyte 2.1.0 Ask: • Is there a non-destructive way to resolve the configmap patch conflict on Helm chart V2 / Airbyte 2.1.0?

Leonardo Muñoz M.

07/03/2026, 8:57 PM

Hello community, I reported an issue regarding the Connector Builder / Declarative CDK a while ago, and I would heavily appreciate it if someone from the team could take a look, as it severely impacts sync performance. When using

incremental_dependency: true

on parent-child streams, the child stream drops its cursor context after the first sync, forcing the parent stream into an unexpected full refresh loop on subsequent syncs (making them 100x–1000x slower). I just updated the issue with a comprehensive root-cause analysis (assisted by GitHub Copilot and verified against the latest Concurrent CDK source code). I also provided: 1. A functional connector-level workaround using custom components (StateMigration) that anyone can apply today. 2. The exact lines in the CDK core (

substream_partition_router.py

) where the context is being lost. Here is the link to the issue: github.com/airbytehq/airbyte/issues/61567 Could you please help review the proposed architectural fix or provide recommendations to get this merged? Thanks!

🙏 1

maria.sanzbe

07/06/2026, 4:28 PM

Hy community! I am having an issue with airbyte connections. This is the error log:

Copy code

// HttpError
{
  "i18nKey": "errors.http.internalServerError",
  "i18nParams": {
    "status": 500
  },
  "name": "HttpError",
  "requestId": "(X)",
  "request": {
    "url": "/api/v1/source_definitions/list_for_workspace",
    "method": "POST",
    "headers": {
      "Content-Type": "application/json"
    },
    "data": {
      "workspaceId": "(x)"
    }
  },
  "status": 500,
  "response": {
    "message": "Internal Server Error: Duplicate key (X) (attempted merging values (X) and (X))",
    "exceptionClassName": "java.lang.IllegalStateException",

The UI shows me duplicated sources but when I query de airbyte db tables with this query it does not appear duplicated:

Copy code

SELECT *
FROM actor
WHERE actor_type = 'source';

I am using the version

2.0.1-alpha-7e24df1

. Anyone else had this issue?

akhilesh.kumar178

07/15/2026, 10:38 AM

1. I tried to use I*ncremental Dedup | Append* mode at the beginning for stores table to replicate from Postgres to Snowflake but syncs failed with an error related to NULL values in the

_id

column. The source table contains rows where

_id

is NULL, and Airbyte's dedup/normalization step could not process these — causing the sync to abort. I checked Postgres stores table and there was no _id column with null values. Airbyte source (postgres) setting was using update method as 'scan changes with user defined cursor'. 2. Switched to Incremental | Append — now seeing duplicate rows: As a workaround we switched to Incremental|Append mode. Syncs now complete successfully, BUT we are seeing duplicate rows in Snowflake destination. What's unusual: all duplicate rows for a given store have the exact same
dateupdated
value. The only difference between duplicate rows is

_AIRBYTE_EXTRACTED_AT

— spaced ~15 minutes apart (our sync frequency). Example — 7 rows for same store in Snowflake, all identical data:

Copy code

Idateupdated = 2026-07-14 12:33:17   _airbyte_extracted_at = 12:46  ← first sync
dateupdated = 2026-07-14 12:33:17   _airbyte_extracted_at = 13:03  ← duplicate
dateupdated = 2026-07-14 12:33:17   _airbyte_extracted_at = 13:17  ← duplicate
dateupdated = 2026-07-14 12:33:17   _airbyte_extracted_at = 13:33  ← duplicate
... and so on

This only affects a small number of stores (~16 out of 243K) at any given time. The affected stores change over time. Question for community: What is causing Incremental|Append + UDC to replicate the same rows repeatedly with identical

dateupdated

? Is this a known behavior and is there a recommended fix short of switching to CDC?

Barush Mendez

08/05/2026, 3:27 PM

Hello community, one connection was deleted from our self hosted airbyte, but it looks like it failed to be deleted and syncs are still being tried to execute and fails over and over, do you guys know how to fix this?

Andrew Kinnersley

08/10/2026, 9:49 AM

We have a self hosted airbyte instance and we are seeing gaps in our connector logs. We are trying to connect to Postgres with connector version 3.8.1 and ingest data. The connector is set up to read data. It successfully runs the discovery mode and reads the schema but then pauses for 10 minutes before exiting without processing any data. If there was no data to read we would expect it to exit immediately? Does anyone have similar experience with the Postgres connector and how did they resolve it. The postgres db is implemented by a 3rd party using neon. Thanks

guillermo.astolfi

08/10/2026, 1:16 PM

Hi everyone! We're running Airbyte OSS (self-hosted) with source-mysql v3.51.5, connecting to a DigitalOcean Managed MySQL instance. We're hitting the exact issue described in #75558 and discussion #74305: Failure in source: Incumbent CDC state is invalid, reason: java.lang.NullPointerException: Cannot invoke "io.debezium.connector.mysql.gtid.MySqlGtidSet$UUIDSet.getUUID()" because "other" is null Some context that might help narrow this down: - This started failing right after a DO-managed maintenance/update event on our MySQL instance (no changes on our end, no connector version change — we're self-hosted so upgrades are manual). - Our server's GTID_EXECUTED currently contains multiple historical server UUIDs (9 in production), accumulated over past failovers/maintenance events over time. This has been the case for a long time without issues. - A full "Clear data + resync" temporarily fixes it, but the very next incremental sync fails again with the same error — consistently, without any further infrastructure change in between. We understand there's a confirmed upstream fix (Debezium DBZ-9682, bumping to 3.4.2.Final) but it hasn't landed in a released source-mysql version yet. Question: does anyone know exactly what the "Incumbent CDC state" validation compares internally? Specifically — is it comparing against GTID_EXECUTED, GTID_PURGED, or the difference between the two? Trying to understand precisely what changes on the MySQL side (e.g. a UUID's range becoming fully purged from retained binlogs) triggers the mismatch, so we can anticipate/avoid it rather than just resetting reactively each time. Thanks in advance for any insight!