https://linen.dev logo
Join Slack
Powered by
# replication-troubleshooting
  • j
    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?
  • a
    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
    k
    m
    • 3
    • 6
  • w
    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
    k
    • 2
    • 1
  • n
    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
    k
    • 2
    • 1
  • d
    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?
    j
    • 2
    • 7
  • n
    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?
    j
    k
    f
    • 4
    • 10
  • a
    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
  • f
    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
    m
    • 2
    • 5
  • r
    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?
    j
    a
    • 3
    • 7
  • c
    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//&lt;vault host&gt;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!
  • m
    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.
    j
    • 2
    • 1
  • g
    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?
  • k
    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!
  • r
    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?
  • l
    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
    f
    • 2
    • 3
  • m
    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?
  • a
    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?
    m
    • 2
    • 1
  • b
    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?
  • a
    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
    a
    • 2
    • 1
  • g
    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!
  • y
    Has anybody encountered an odd error on the postgres cdc connector erroring out on a message (
    'A'
    )? It looks like the Debezium decoder in 
    source-postgres:3.8.4
    crashed on a PostgreSQL WAL Stream Abort message (
    'A'
    ) emitted, but this never happened to me
    r
    • 2
    • 3
  • g
    Hey all πŸ‘‹ β€” hoping someone's hit this before. Self-hosted OSS, and I'm fully stuck. Context: this broke right after doing two things together: EKS 
    1.34 β†’ 1.35
    upgrade, and Airbyte Helm chart 
    0.551.0 β†’ 1.9.2
    (big jump, I know πŸ˜…). Since then, syncs never actually run. Symptom: jobs sit at "Starting..." forever. No replication pod is ever created β€” watched 
    kubectl get pods -n airbyte -w
    live while triggering a sync, nothing appears, across multiple attempts. What I've ruled out so far: β€’ RBAC β€” 
    airbyte-admin
    SA can create pods (
    kubectl auth can-i create pods --as=system:serviceaccount:airbyte:airbyte-admin
    β†’ 
    yes
    ) β€’ DNS/networking between internal services β€” all fine β€’ 
    kubectl get events -n airbyte
    β€” zero `FailedCreate`/`Forbidden`/rejections, ever β€’ 
    workload-launcher
    β€” pod's healthy, only logging routine pod-sweeper cycles, nothing about the actual job β€’ 
    workload-api-server
    β€” healthy, responds fine to other calls The actual weird part: using 
    tctl workflow show -w replication_<jobid>
    , the 
    StartCommand
    activity completes successfully and returns a workload ID. But hitting that exact ID directly against workload-api-server:
    Copy code
    GET /api/v1/workload/replication_<jobid>_...
β†’ {"message":"Could not find workload with id: ..."}
    So the worker's activity thinks it created the workload and gets an ID back β€” but the server has zero record of it. No errors anywhere in worker/workload-launcher/workload-api-server logs about this specific job β€” total silence. Also noticed the chart's default images for `container-orchestrator`/`workload-init-container`/`connector-sidecar`/`async-profiler` are pinned to an alpha build (
    2.0.2-alpha-c905e75
    ) rather than a stable tag β€” not sure if related, but seemed worth mentioning. Has anyone seen `StartCommand`/`createWorkload` report success while the workload record never actually persists server-side? Any pointer on where that write might be dying between worker β†’ workload-api-server would save my week πŸ™
    a
    • 2
    • 3
  • j
    Hi everyone, When an Airbyte sync fails prematurely (e.g., due to an image pull failure from the registry) with 0 records synced, Airbyte is still reporting the status as Successful. This false-positive status makes it easy to miss silent failures. I noticed an open issue tracking this on GitHub (Replication pod creation fails (KubeClientException) but UI/Public API still reports sync as successful Β· Issue #72448 Β· airbytehq/airbyte), but in the meantime, I wanted to check: how are others currently detecting and handling these false-positive syncs? Any workarounds or monitoring approaches you’d recommend?
  • j
    Has anyone had to deal with syncing User-Defined Types (UDTs) from MS SQL Server? These don't show up for me at all in schema discovery, so those fields just get dropped completely. Normal types on the same table are fine. I'm using non-CDC syncs for this connection. Unfortunately I don't have any permissions on the remote side, so I can't just make a view to work around it. Is there any way to get Airbyte to just treat these as string/text types?
    a
    • 2
    • 3
  • n
    Hi everyone, I'm using the Paypal Transacion source connector, and pulling data from the list_disputes stream. I have recently encountered with an error, and after a short investigation I've noticed that the connector is using 
    next_page_token
     for pagination. This field was deprecated in the provider's API - developer.paypal.com/api/customer-disputes/v1/disputes-list Increasing the page size so all records will fit in a single page is currently not supported (fixed at 50 per page). Is there a plan for fixing this? any workaround until then? πŸ™
    πŸ‘€ 1
    r
    • 2
    • 4
  • y
    Hi all! We’re seeing repeated Postgres CDC slot invalidations and would appreciate help determining whether this is a connector checkpointing issue. Setup/behavior: β€’ Postgres source 
    3.8.5
    β†’ BigQuery, PostgreSQL 
    18.1
    on Cloud SQL, 
    After loading Data in the destination
    , 
    initial_waiting_seconds=2400
    , and 
    max_slot_wal_keep_size=3 TiB
    . We also have a working heartbeat-table upsert every 10 seconds. β€’ The connection alternates between empty syncs and large bursts. One job spent 40 minutes searching for its saved WAL position, received 238 heartbeat events, emitted no records, and ended with 
    HEARTBEAT_NOT_PROGRESSING
    . The next job found the same position after 17 minutes and emitted 3.72M records, but committed zero state before the slot was invalidated. β€’ WAL is generated at approximately 173–190 GB/hour, while the decoded LSN advances at 507–545 GB/hour. However, 
    restart_lsn
    barely advances, so retained WAL eventually exceeds 3 TiB. Should long CDC jobs commit intermediate destination-acknowledged checkpoints? Is there a safe way to advance 
    confirmed_flush_lsn
    during long jobs while retaining β€œAfter loading” safety? Could this be related to issue #70887, and is there a recommended patch or configuration?
  • t
    Hi everyone, We are currently planning a major upgrade of our self-hosted Airbyte instance, migrating from version 
    0.59.1
    to 
    2.3.0
    . We rely heavily on the Declarative CDK and have dozens of custom connectors. Because of this scale, recreating each of them manually from scratch via the Connector Builder UI is completely unfeasible for our team. Initially, we tried the straightforward approach: exporting the YAML manifest from the obsolete version and importing it directly into the new version's Connector Builder. However, this approach throws validation errors and fails to save the draft. Since a simple UI import doesn't work for these legacy manifests, we are looking for suggestions on how to best handle this transition. What is the officially recommended approach to migrate and deploy these legacy YAML manifests into v2.3.0? Any guidance or documentation you could share would be hugely appreciated! Thanks in advance.
    a
    j
    • 3
    • 2
  • a
    Hello everyone, We are using Airbyte 1.8.3 and now frequently we are getting ahead lsn. We have source as PG 18 and destination as BigQuery. Replication slot 'airbyte_ilmcore_issues_slot' has advanced beyond the source's state LSN. Confirmed flush LSN: LSN{4F18/D61C3FC0}, source LSN: LSN{4F15/B558F888}. Can someone help here?
    j
    • 2
    • 1
  • i
    @ajaya Ahead LSN usually happens when Postgres drops or advances the replication slot during an ungraceful crash or WAL segment recycling, while Airbyte state still points to an older committed position. If you can not rewind Postgres WAL, dropping the slot in Postgres and triggering a reset or full refresh on that stream from Airbyte is the only reliable fix.
  • n
    Hi all! If this is the wrong channel, please point me to the right one and I'll move it. πŸ™ We self-host Airbyte (Helm chart 1.7.1) on GKE and I'm trying to benchmark our infra cost against how others run theirs. If you self-host on Kube (GKE, EKS, AKS or other), would you be willing to share a rough picture? LIke for example: "about 100 syncs, data volume of 100GB/month, about $600/month". Thank you!