@kapa.ai AsyncRetriever resulted in this error: Failed to parse JSON data using json library. 'utf-8' codec can't decode byte 0x8b in position 1: invalid start byte

GZIP Encoding Issue with AsyncRetriever The error

'utf-8' codec can't decode byte 0x8b in position 1: invalid start byte

is a classic symptom of receiving GZIP-compressed data that isn't being decoded before JSON parsing. The byte

0x8b

is part of the GZIP magic number (

0x1f 0x8b

). This exact issue was encountered with the

source-amazon-ads

connector when the API returns GZIP-compressed content without a

Content-Encoding: gzip

header, causing the low-code CDK's

GzipDecoder

to fail. [Amazon Ads GZIP Issue] Workaround A known temporary fix is to nest

GzipDecoder

twice in your manifest. This causes the decoder to default to treating the content as gzip regardless of the missing

Content-Encoding

header:

download_decoder:
  type: GzipDecoder
  decoder:
    type: GzipDecoder
    decoder:
      type: JsonDecoder
      encoding: utf-8

This was tested on real data and confirmed to work. [Amazon Ads GZIP Issue] Permanent Fix The root cause is that

GzipDecoder

should default to treating content as gzip even when the

Content-Encoding

header is absent. This was addressed in the CDK updates shipped with source-amazon-ads v7.2.0 and the subsequent manifest-only migration in v7.3.0. [Amazon Ads GZIP Issue] If you are using a custom connector or a different source connector with

AsyncRetriever

, the double-nested

GzipDecoder

workaround above should resolve the issue until the underlying CDK fix is available for your connector version. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

How to upgrade airbyte cdk version of self host airbyte cluster on k8s

The knowledge sources do not contain enough information to provide a complete answer specifically about upgrading the Airbyte CDK version on a self-hosted Kubernetes cluster. However, here is what the knowledge sources do cover: Upgrading Airbyte CDK on Self-Hosted Kubernetes 1. Upgrade Airbyte Platform (Helm) Upgrading the Airbyte platform itself (which pulls in updated connector images with newer CDK versions) is done via Helm:

helm upgrade airbyte airbyte/airbyte \
  --namespace airbyte \
  --values ./values.yaml \
  --version 2.x.x

Check available versions on ArtifactHub and review release notes before upgrading. [Upgrading Airbyte] 2. Update Individual Connector Images (CDK version is bundled per connector) The CDK version is bundled inside each connector's Docker image — it is not a standalone component you upgrade separately. To get a newer CDK version, you update the connector itself: 1. Go to Workspace settings (or Organization settings for Enterprise) > *Sources*/*Destinations*. 2. Find the connector you want to update. 3. Click Change to pull the latest available image, then click Upgrade. [Managing Connector Updates] 3. Pin a Specific Connector Version (Optional) If you need a specific CDK version (via a specific connector version), you can pin it: 1. Go to Workspace/Organization settings > *Sources*/*Destinations*. 2. Edit the connector entry. 3. Set the Default Version to the desired version. [Managing Connector Updates] > Note: If you are building a custom connector and want to upgrade the CDK in its source code, you would update the

airbyte-cdk

dependency in

pyproject.toml

(for Python connectors) or

gradle.properties

(for Java/Kotlin connectors) and rebuild the Docker image. However, the knowledge sources do not provide a detailed step-by-step guide for this specific workflow on self-hosted Kubernetes. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai but I am developing connector on builder

The knowledge sources do not contain enough detailed information to provide a complete guide for upgrading the CDK version specifically used by the Connector Builder on a self-hosted Kubernetes cluster. However, here is what the knowledge sources do reveal: CDK Version in Connector Builder (Self-Hosted K8s) How the CDK Version Works in Builder When using Connector Builder, the CDK version is determined by two components: • The

connector-builder-server

pod — used during testing/building in the UI • The

source-declarative-manifest

Docker image — used at runtime during actual syncs These two can be different versions, which can cause inconsistencies. [Connector Builder CDK] How to Check Your Current CDK Version You can check the CDK version running in your cluster:

kubectl exec -it <airbyte-connector-builder-server-pod> -- pip list | grep airbyte-cdk

Or check the Python version too:

kubectl exec -it <airbyte-connector-builder-server-pod> -- python --version

[Connector Builder CDK] How to Upgrade The CDK version in Connector Builder is tied to the Airbyte platform version. To get a newer CDK version, you need to upgrade Airbyte itself via Helm:

helm upgrade airbyte airbyte/airbyte \
  --namespace airbyte \
  --values ./values.yaml \
  --version 2.x.x

[Upgrading Airbyte] > Important: There is a known issue on self-hosted deployments where the

connector-builder-server

and the

source-declarative-manifest

runtime image can be out of sync. Airbyte has acknowledged this and worked on fixing it, but the knowledge sources do not provide a manual workaround beyond upgrading the platform. [Connector Builder CDK] For more specific guidance, it is recommended to reach out on the Airbyte Slack or community forum. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai source declarative manifest image of 7.0.1 is equivalent to airbyte cdk 7.0.1 right?

Based on the knowledge sources, yes — the

source-declarative-manifest

image version directly corresponds to the

airbyte-cdk

version of the same number. This is confirmed by a community member who verified it by inspecting the running container: [Connector Builder CDK]

docker run --rm --entrypoint="" -it airbyte/source-declarative-manifest:6.5.2 bash

# Inside the container:
python --version
# Python 3.10.14

pip list | grep airbyte-cdk
# airbyte-cdk   6.5.2

So

source-declarative-manifest:6.5.2

contained

airbyte-cdk 6.5.2

, confirming the 1:1 version mapping. This is also consistent with how Airbyte manages connector updates — for example, PRs upgrading connectors explicitly align the

baseImage

tag and the

airbyte-cdk

dependency to the same version number (e.g., both set to

7.15.0

,

7.17.3

,

7.19.2

, etc.). [CDK Update PR] [CDK Update PR] So

source-declarative-manifest:7.0.1

should contain

airbyte-cdk 7.0.1

— the versions are intentionally kept in sync. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.