Minified React error #185; visit https://reactjs.org/docs/error-decoder.html?invariant=185 for the full message or use the non-minified dev environment for full errors and additional helpful warnings. @kapa.ai

Minified React Error #185 in Airbyte This error indicates a "Maximum update depth exceeded" issue — a React component is repeatedly calling

setState

in a loop, causing infinite re-renders. There are two known occurrences of this in Airbyte: 1. Error on the /setup page (Airbyte 2.1.0) A user reported this error when accessing

http://localhost:8000/setup

after installing via

abctl local install

. Workaround: Disabling Basic Auth resolved the issue. You can do this by creating a

values.yaml

file:

global:
  auth:
    enabled: false

Then reinstalling with:

abctl local install --port 8001 --values ./values.yaml

[Setup page issue] 2. Error on the connection page (Airbyte 1.4.1) A similar React error #185 was reported on the connection page after leaving it idle for some time. This issue was closed as stale without a confirmed fix, and it's possible it was resolved in a later version. [Connection page issue] General Troubleshooting Tips • Try a different browser or an incognito/private window to rule out cached assets. • Check if the error appears immediately or only after interacting with a specific field/step. • Review browser console logs for a component stack trace. • Check webapp pod logs:

kubectl logs -n airbyte-abctl deploy/airbyte-abctl-webapp

If none of these help, consider reaching out on the Airbyte Community Slack for peer support. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

Верный ли у нас контейнеры для версии 2.1.0 chart?

jobs:
  resources:
    requests:
      cpu: 250m   # 0.25 ядра
      memory: 512Mi
    limits:
      cpu: 1      # 1 ядро
      memory: 1536Mi # 1.5 ГБ

worker:
  replicaCount: 2
  maxSyncWorkers: 3
  maxCheckWorkers: 2
  maxDiscoverWorkers: 2
  maxSpecWorkers: 2
  resources:
    requests:
      cpu: 500m
      memory: 1Gi
    limits:
      cpu: 2
      memory: 2Gi

workloadLauncher:
  replicaCount: 1
  # Этот параметр ограничивает общее количество одновременно запускаемых задач
  parallelism: 3
  resources:
    requests:
      cpu: 500m
      memory: 512Mi
    limits:
      cpu: 2
      memory: 2Gi

server:
  replicaCount: 1
  resources:
    requests:
      cpu: 250m
      memory: 512Mi
    limits:
      cpu: 1
      memory: 2Gi

temporal:
  resources:
    requests:
      cpu: 250m
      memory: 512Mi
    limits:
      cpu: 1
      memory: 2Gi

workloadApiServer:
  resources:
    requests:
      cpu: 250m
      memory: 512Mi
    limits:
      cpu: 1
      memory: 2Gi

connector-builder-server:
  enabled: true
  resources:
    requests:
      cpu: 250m
      memory: 256Mi
    limits:
      cpu: 1
      memory: 512Mi

В вашей конфигурации есть несколько проблем, связанных с Helm chart V2 (версия 2.1.0). Проблемы 1. jobs.resources — устаревший ключ В Helm chart V2 ключ

jobs.resources

заменён на

global.workloads.resources

. Правильный путь для ресурсов контейнеров задач:

global:
  workloads:
    resources:
      replication:
        cpu:
          request: "250m"
          limit: "1"
        memory:
          request: 512Mi
          limit: 1536Mi

Или через старые env-переменные, которые теперь маппируются так: [Helm V2 migration] 2. connector-builder-server — удалён в 2.1.0 Компонент

connector-builder-server

удалён из Helm chart в версии 2.1.0 и заменён на manifest server. Конфигурация переехала под

server.connectorBuilder.*

. [Airbyte 2.1 release] 3. maxDiscoverWorkers, maxSpecWorkers — используйте extraEnvs Эти параметры не имеют прямых ключей в Helm chart V2 и должны передаваться через

extraEnvs

. [Helm V2 migration] Исправленная конфигурация

global:
  workloads:
    resources:
      mainContainer:
        cpu:
          request: "250m"
          limit: "1"
        memory:
          request: 512Mi
          limit: 1536Mi

worker:
  replicaCount: 2
  maxSyncWorkers: 3
  maxCheckWorkers: 2
  resources:
    requests:
      cpu: 500m
      memory: 1Gi
    limits:
      cpu: 2
      memory: 2Gi
  extraEnv:
    - name: MAX_DISCOVER_WORKERS
      value: "2"
    - name: MAX_SPEC_WORKERS
      value: "2"

workloadLauncher:
  replicaCount: 1
  parallelism: 3
  resources:
    requests:
      cpu: 500m
      memory: 512Mi
    limits:
      cpu: 2
      memory: 2Gi

server:
  replicaCount: 1
  resources:
    requests:
      cpu: 250m
      memory: 512Mi
    limits:
      cpu: 1
      memory: 2Gi

temporal:
  resources:
    requests:
      cpu: 250m
      memory: 512Mi
    limits:
      cpu: 1
      memory: 2Gi

workloadApiServer:
  resources:
    requests:
      cpu: 250m
      memory: 512Mi
    limits:
      cpu: 1
      memory: 2Gi

> ⚠️ Точная структура

global.workloads.resources

в версии 2.1.0 может отличаться. Рекомендую сверяться с актуальным values.yaml на GitHub. [Values reference] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements

Ошибка на версии 2.1.0 Unsetting empty environment variable 'AWS_SECRET_MANAGER_REGION' Unsetting empty environment variable 'DATA_PLANE_SERVICE_ACCOUNT_CREDENTIALS_PATH' Unsetting empty environment variable 'DATA_PLANE_SERVICE_ACCOUNT_EMAIL' Unsetting empty environment variable 'VAULT_PREFIX' Unsetting empty environment variable 'AB_AZURE_KEY_VAULT_TENANT_ID' Unsetting empty environment variable 'SECRET_STORE_GCP_PROJECT_ID' Unsetting empty environment variable 'AWS_SECRET_MANAGER_SECRET_TAGS' Unsetting empty environment variable 'AB_AZURE_KEY_VAULT_VAULT_URL' Unsetting empty environment variable 'FEATURE_FLAG_BASEURL' Unsetting empty environment variable 'VAULT_ADDRESS' Unsetting empty environment variable 'AB_AZURE_KEY_VAULT_TAGS' Unsetting empty environment variable 'LAUNCHDARKLY_KEY' Unsetting empty environment variable 'AWS_KMS_KEY_ARN' Unsetting empty environment variable 'S3_PATH_STYLE_ACCESS' 2026-06-08 134948,104 [main] INFO i.a.i.ApplicationKt(main):14 - Init start 2026-06-08 134949,327 [main] INFO i.m.c.e.DefaultEnvironment(<init>):170 - Established active environments: [worker-v2, k8s, control-plane, edition-community, local-secrets] 2026-06-08 134950,510 [main] INFO c.z.h.HikariDataSource(<init>):79 - config-pool - Starting... 2026-06-08 134950,532 [main] INFO c.z.h.HikariDataSource(<init>):81 - config-pool - Start completed. 2026-06-08 134951,074 [main] INFO i.a.i.InputFetcher(fetch):31 - Fetching workload... 2026-06-08 134952,109 [main] ERROR i.a.i.InputFetcher(failWorkloadAndExit):62 - Init container error encountered while fetching workload for id: c8c28de8-d675-4eb6-98a1-bf678bbbd203_76916_0_check. Attempting to fail workload... io.airbyte.api.client.ApiException: Unauthorized at io.airbyte.workload.api.client.WorkloadApiClient.workloadGet(WorkloadApiClient.kt:268) at io.airbyte.initContainer.InputFetcher.fetch(InputFetcher.kt:35) at io.airbyte.initContainer.ApplicationKt.main(Application.kt:32) at io.airbyte.initContainer.ApplicationKt.main(Application.kt) 2026-06-08 134952,185 [main] ERROR i.a.i.InputFetcher(failWorkloadAndExit):75 - Error encountered failing workload for id: c8c28de8-d675-4eb6-98a1-bf678bbbd203_76916_0_check. Ignoring... io.airbyte.api.client.ApiException: Unauthorized at io.airbyte.workload.api.client.WorkloadApiClient.unit(WorkloadApiClient.kt:417) at io.airbyte.workload.api.client.WorkloadApiClient.workloadFailure(WorkloadApiClient.kt:54) at io.airbyte.initContainer.InputFetcher.failWorkloadAndExit(InputFetcher.kt:67) at io.airbyte.initContainer.InputFetcher.fetch(InputFetcher.kt:38) at io.airbyte.initContainer.ApplicationKt.main(Application.kt:32) at io.airbyte.initContainer.ApplicationKt.main(Application.kt) 2026-06-08 134952,203 [main] INFO c.z.h.HikariDataSource(close):349 - config-pool - Shutdown initiated... 2026-06-08 134952,206 [main] INFO c.z.h.HikariDataSource(close):351 - config-pool - Shutdown completed. 2026-06-08 134952,209 [main] INFO i.a.i.ApplicationKt(main):40 - Init end with error 2 @kapa.ai

Ошибка Unauthorized в init-контейнере (Airbyte 2.1.0) Ошибка чёткая:

io.airbyte.api.client.ApiException: Unauthorized
at io.airbyte.workload.api.client.WorkloadApiClient.workloadGet

Init-контейнер не может аутентифицироваться в Workload API Server — у него отсутствуют

WORKLOAD_API_AUTH_HEADER

и

WORKLOAD_API_BEARER_TOKEN

. Причина Это известная проблема:

workload-launcher

не передаёт токены аутентификации в создаваемые им init/sidecar-контейнеры. [Connector-Sidecar Auth issue] Решение Шаг 1: Включите авторизацию в ConfigMap Убедитесь, что в ConfigMap

airbyte-airbyte-env

установлено:

API_AUTHORIZATION_ENABLED=true

Шаг 2: Добавьте токены в values.yaml Токен должен быть одинаковым во всех компонентах:

workloadApiServer:
  extraEnv:
    - name: WORKLOAD_API_AUTH_HEADER
      value: "Authorization"
    - name: WORKLOAD_API_BEARER_TOKEN
      value: "ваш-токен"

worker:
  extraEnv:
    - name: WORKLOAD_API_AUTH_HEADER
      value: "Authorization"
    - name: WORKLOAD_API_BEARER_TOKEN
      value: "ваш-токен"

workloadLauncher:
  extraEnv:
    - name: WORKLOAD_API_AUTH_HEADER
      value: "Authorization"
    - name: WORKLOAD_API_BEARER_TOKEN
      value: "ваш-токен"

⚠️ Важное замечание Даже после этих настроек существует известный баг:

workload-launcher

корректно передаёт токены в sync-поды, но не передаёт их в check/discover-поды (init и sidecar контейнеры). [Connector-Sidecar Auth issue] Проверьте, передаются ли переменные в init-контейнер:

kubectl get pod <имя-пода-check> -n airbyte -o json | \
  jq '.spec.initContainers[0].env[] | select(.name | contains("WORKLOAD_API"))'

Если

WORKLOAD_API_BEARER_TOKEN

отсутствует — это подтверждает баг в

workload-launcher

. На момент написания этот баг остаётся открытым и официального фикса в знаниях нет. Рекомендую следить за обновлениями в [issue #70451]. 👍 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

Где взять значение токена Токен генерируется случайным образом. Есть несколько способов: Способ 1: Через openssl (рекомендуется)

openssl rand -hex 24

Способ 2: Проверить существующий секрет в Kubernetes Возможно, токен уже создан Airbyte при установке. Проверьте:

kubectl get secret airbyte-airbyte-secrets -n airbyte -o jsonpath='{.data}'

Значение будет в base64, декодируйте его:

kubectl get secret airbyte-airbyte-secrets -n airbyte \
  -o jsonpath='{.data.WORKLOAD_API_BEARER_TOKEN}' | base64 -d

[Upgrade to Helm V2] > Важно: Используйте одно и то же значение токена во всех компонентах (

workloadApiServer

,

worker

,

workloadLauncher

). Токен — это просто случайная строка, главное чтобы она совпадала везде. [Connector-Sidecar Auth issue] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

У нас почему то не стартуют задачи у старует source check потом destination check потом пода создается replication job И логи у нее пустые что делать в чем проблема? Что тебе скинуть для диагностики? @kapa.ai

Диагностика: replication job pod запускается, но логи пустые Это типичная картина когда под создаётся, но не может начать работу. Для диагностики нужно собрать следующее: 1. Логи workload-launcher

kubectl logs -n airbyte deploy/airbyte-workload-launcher --tail=100

2. События в namespace

kubectl get events -n airbyte --sort-by='.lastTimestamp' | tail -30

3. Описание самого replication пода

# Найдите имя пода
kubectl get pods -n airbyte | grep replication

# Описание
kubectl describe pod <имя-replication-пода> -n airbyte

4. Логи всех контейнеров replication пода

# init-контейнер
kubectl logs <имя-replication-пода> -n airbyte -c init

# основной контейнер
kubectl logs <имя-replication-пода> -n airbyte -c main

# sidecar
kubectl logs <имя-replication-пода> -n airbyte -c connector-sidecar

5. Статус workload в БД (если есть доступ)

kubectl exec -n airbyte deploy/airbyte-db -- psql -U airbyte \
  -c "SELECT id, status, updated_at FROM workload ORDER BY updated_at DESC LIMIT 10;"

Наиболее вероятные причины (исходя из контекста) Скиньте вывод команд выше — смогу точнее определить причину. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements

а как правильно прописать global ресурсы именно для helm chart v2? @kapa.ai

Глобальные ресурсы в Helm chart V2 В Helm chart V2 ресурсы для job-контейнеров (replication, check, discover) настраиваются через

global.workloads.resources

, а не через

global.jobs.resources

как в V1. [Helm V2 migration]

global:
  workloads:
    resources:
      # Ресурсы для replication (sync) задач
      replication:
        cpu:
          request: "250m"
          limit: "1"
        memory:
          request: 512Mi
          limit: 1536Mi

      # Ресурсы для check задач
      check:
        cpu:
          request: "250m"
          limit: "1"
        memory:
          request: 256Mi
          limit: 512Mi

      # Ресурсы для discover задач
      discover:
        cpu:
          request: "250m"
          limit: "1"
        memory:
          request: 256Mi
          limit: 512Mi

Таблица соответствия V1 → V2 [Helm V2 migration] ⚠️ Важно Существует открытый баг:

global.jobs.resources

присутствует в values.yaml но не работает в Helm chart V2 — значения игнорируются. Правильный путь именно

global.workloads.resources.*

. [global.jobs.resources broken] Для точной актуальной структуры рекомендую сверяться с официальным файлом: [Values reference] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements

What is the impact of disabling basic auth @kapa.ai

Impact of Disabling Basic Auth When you disable basic auth in Airbyte by setting:

global:
  auth:
    enabled: false

The following impacts apply: Security • The Airbyte UI and API become completely open — anyone with network access can use them without any credentials. [Authentication docs] • Both the web UI and the API lose protection simultaneously — it is not currently possible to disable auth for the UI while keeping the API secured separately. [Helm community discussion] When it's acceptable • You have a reverse proxy or firewall in front of Airbyte that handles authentication/SSO at the network level. [Authentication docs] • You are deploying in a fully private network with no external access. • On GCP/AWS you can use Identity-Aware Proxy or AWS Systems Manager Session Manager as a replacement. [Security docs] Known workaround use case Disabling auth has been used as a workaround for the Minified React error #185 on the

/setup

page in version 2.1.0. [Setup page issue] > ⚠️ Bottom line: Never disable auth on a publicly accessible instance without an alternative security layer in place. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

Why is there an auth dialog popup as well as a login page in a dev deployment? @kapa.ai

Auth Dialog Popup + Login Page in Dev Deployment This is a known bug in Airbyte self-hosted deployments. Two auth prompts appear because of a mismatch between the browser's native HTTP Basic Auth dialog and Airbyte's HTML login page. [Bug report] Root Cause On page load, the webapp makes a session probe request:

POST /api/v1/users/get

When no session cookie exists, the server returns a

401

response — but also includes this header:

WWW-Authenticate: Basic charset="UTF-8", realm="airbyte-server", Bearer resource_metadata="..."

Browsers interpret this as an HTTP Basic Auth challenge and show the native OS/browser "Sign in" dialog, before Airbyte's own HTML login page appears. This is standard browser behaviour — JavaScript cannot suppress this dialog programmatically. [Bug report] Workaround 1: Cancel the dialog Simply click Cancel on the native browser dialog — Airbyte's normal HTML login UI will then appear. [Bug report] Workaround 2: Hide the WWW-Authenticate header via nginx

docker exec airbyte-abctl-control-plane kubectl patch configmap ingress-nginx-controller \
  -n ingress-nginx --type merge \
  -p '{"data":{"http-snippet":"proxy_hide_header WWW-Authenticate;"}}'

[Bug report] Workaround 3: Disable auth entirely (dev only)

global:
  auth:
    enabled: false

> ⚠️ Only use this in a dev/local environment — disabling auth leaves your instance completely unprotected. The Airbyte team has acknowledged the issue and escalated it for investigation, but there is no official fix yet. [Bug report] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.