https://linen.dev logo
Join Slack
Powered by
<@U04S8PLJWMT> I did the upgrade to airbyte 1.8.2 ...
# replication-ask-ai
t
@kapa.ai I did the upgrade to airbyte 1.8.2 with the helm chart as well but now, when I click on testing source connections or destination connections, airbyte is doing nothing in background. Usually it would launch a new pod testing the connection, but here none of that happen. Any idea why or reported bug ?
k
There are a few reports of very similar behavior after Helm-based upgrades, but nothing in the knowledge sources points to a single confirmed bug specific to chart 
1.8.2
. Relevant patterns: - In multiple cases, after upgrading via Helm, **“check connection” does nothing and no check pod is ever created**; the worker appears “stuck” and Kubernetes shows no new pods. [[Temporal context issue](https://github.com/airbytehq/airbyte/issues/59730)] - For Airbyte 2.x, a related symptom (“no new job pods are launched”) was traced to dataplane group misconfiguration / mismatch after upgrade; jobs were queued but never claimed. A workaround was to align the dataplane group configuration (e.g., 
global.dataplaneGroups
and default group name) with what the upgraded instance expects. [[Jobs not launched](https://github.com/airbytehq/airbyte/issues/68115)] However, the knowledge sources: - Do not explicitly document a known bug for Helm chart 1.8.2 where connection tests never start. - Do not provide a step‑by‑step fix for this exact version/symptom. Given that limitation, the best guidance we can derive from the existing issues is: 1. Check worker / launcher / temporal logs In similar cases, the worker or workload launcher was running but not claiming jobs; logs there were the key to understanding why no pods were created. [[Jobs not launched](https://github.com/airbytehq/airbyte/issues/68115); [Temporal context issue](https://github.com/airbytehq/airbyte/issues/59730)] 2. Verify that jobs are being enqueued at all In the 2.x dataplane issues, jobs were stuck in “Queued” because they were being pushed to one dataplane group while the launcher listened to another. [[Jobs not launched](https://github.com/airbytehq/airbyte/issues/68115)] While this is documented for 2.x, a similar “jobs queued but never claimed” situation could manifest as “nothing happens” on 1.8.x. 3. Confirm your Helm values after upgrade Some users upgrading via Helm had to adjust configuration (e.g., dataplane-related values in newer charts, Temporal settings) to restore job execution. [[Jobs not launched](https://github.com/airbytehq/airbyte/issues/68115); [Temporal context issue](https://github.com/airbytehq/airbyte/issues/59730)] Because the sources don’t describe a confirmed 1.8.2 bug matching your exact scenario, I can’t point to a definitive fix. The next concrete step, based on the patterns above, would be: - Inspect logs from 
airbyte-worker
, 
workload-launcher
(if present in your version), and Temporal when you click “Test connection”. - If you see messages about workloads not being claimed or timeouts to Temporal, your issue is likely in the same family as the linked ones, and you may need to adjust your Helm values or dataplane/Temporal configuration. If you can share specific log snippets (with secrets removed), that’s typically what Airbyte maintainers used in the referenced issues to diagnose why no pods were being launched.
t
@kapa.ai who is supposed to start these pods normally ? So I can now where to look for logs ?
k
A message from kapa.ai
A message from kapa.ai
In your Kubernetes/Helm deployment, the pods for “Test connection” (CHECK/DISCOVER/SPEC) and syncs are launched by the Workload API + Workload Launcher path, not directly by the UI: 1. High‑level flow (1.8.x / Workloads architecture) - The UI/API requests a CHECK/DISCOVER/SPEC or SYNC job. - A worker process talks to the Workload API Server, which enqueues a workload (an internal job object). - The Workload Launcher then picks up that workload and creates the Kubernetes pod(s) needed to run the connector. [[Jobs & workloads 1.8](https://docs.airbyte.com/platform/1.8/understanding-airbyte/jobs)] 2. Where to look for logs when pods don’t appear Based on this architecture, the most relevant components to inspect are: - Workload Launcher pod logs (this is what actually calls the Kubernetes API to create the job pods). [[Jobs & workloads 1.8](https://docs.airbyte.com/platform/1.8/understanding-airbyte/jobs)] - Worker logs (they submit workloads and may show errors talking to the Workload API or Temporal). [[Temporal context issue](https://github.com/airbytehq/airbyte/issues/59730)] - Optionally, Kubernetes events in the Airbyte namespace to see if pod creation is failing at the cluster level. [[Replication pod failure](https://github.com/airbytehq/airbyte/issues/72448)] So for your “nothing happens / no pod created” symptom, start by checking:
Copy code
bash # Workload launcher kubectl logs -l <http://app.kubernetes.io/name=workload-launcher|app.kubernetes.io/name=workload-launcher> -n <airbyte-namespace> --tail=200  # Worker kubectl logs -l <http://app.kubernetes.io/name=worker|app.kubernetes.io/name=worker> -n <airbyte-namespace> --tail=200  # Any FailedCreate events kubectl get events -n <airbyte-namespace> --field-selector reason=FailedCreate
In the current Workloads architecture, the component responsible for creating those Kubernetes pods is the Workload Launcher, which talks to the Kubernetes API and starts the actual workload pods (check/discover/spec or sync). [[Jobs overview](https://docs.airbyte.com/platform/1.8/understanding-airbyte/jobs)] The flow is: 1. A “Test connection” request creates a Workload via the Workload API Server. 2. The Launcher picks up that workload from the queue and launches the Kubernetes pod(s) needed to run it. [[Jobs overview](https://docs.airbyte.com/platform/1.8/understanding-airbyte/jobs)] So for debugging “no pod is started” you should primarily check logs for: - The workload-launcher pod (this is where pod creation errors and “Failed to create pod …” messages show up). [[Failed pod creation](https://github.com/airbytehq/airbyte/issues/52034); [Init container failure](https://github.com/airbytehq/airbyte/issues/48809)] - The Temporal / worker side, to see if workflows are being scheduled but workloads are not being claimed or are stuck. [[Jobs not launched](https://github.com/airbytehq/airbyte/issues/68115)] If you don’t see any new workload pods and no errors in 
workload-launcher
, it’s likely the problem is earlier in the chain (Temporal / worker / Workload API), but the first place to look for “why no pod was created” is 
workload-launcher
logs.
A message from kapa.ai
In Airbyte’s Workloads architecture, the pods for checks/syncs are created by the Workload Launcher, not directly by the UI or server. Flow (1.8.x and later): 1. UI/API requests a CHECK/DISCOVER/SPEC or SYNC. 2. A Workload is created and queued by the Workload API Server. 3. The Launcher picks up that workload and creates the Kubernetes pod(s) for the connector operation. [[Jobs & workloads](https://docs.airbyte.com/platform/1.8/understanding-airbyte/jobs)] So for “no pod is started” issues, the main places to look are: - 
workload-launcher
pod logs – this is what actually calls the K8s API to create pods. [[Jobs & workloads](https://docs.airbyte.com/platform/1.8/understanding-airbyte/jobs)] - Worker / Temporal side if workloads are not being claimed or are stuck (seen in similar “no new job pods are launched” reports). [[Jobs stuck](https://github.com/airbytehq/airbyte/issues/68115)] Example commands:
Copy code
bash kubectl logs -l <http://app.kubernetes.io/name=workload-launcher|app.kubernetes.io/name=workload-launcher> -n <airbyte-namespace> --tail=200 kubectl logs -l <http://app.kubernetes.io/name=worker|app.kubernetes.io/name=worker> -n <airbyte-namespace> --tail=200
t
In workload-launcher pod, I have a lot of errors like this : 
2026-02-18 15:41:57,677 [parallel-2]	WARN	i.a.w.l.p.c.WorkloadApiQueuePoller(handlePollError):98 - Error encountered in poller: io.airbyte.workload.api.client.generated.infrastructure.ClientException: Client error : 401 Unauthorized {"message":"Unauthorized","logref":null,"path":null,"_links":{"self":{"href":"/api/v1/workload/queue/poll","templated":false,"profile":null,"deprecation":null,"title":null,"hreflang":null,"type":null,"name":null}},"_embedded":{"errors":[{"message":"Unauthorized","logref":null,"path":null,"_links":{},"_embedded":{}
@kapa.ai In workload-launcher pod, I have a lot of errors like this : 
2026-02-18 15:41:57,677 [parallel-2]	WARN	i.a.w.l.p.c.WorkloadApiQueuePoller(handlePollError):98 - Error encountered in poller: io.airbyte.workload.api.client.generated.infrastructure.ClientException: Client error : 401 Unauthorized {"message":"Unauthorized","logref":null,"path":null,"_links":{"self":{"href":"/api/v1/workload/queue/poll","templated":false,"profile":null,"deprecation":null,"title":null,"hreflang":null,"type":null,"name":null}},"_embedded":{"errors":[{"message":"Unauthorized","logref":null,"path":null,"_links":{},"_embedded":{}
k
A message from kapa.ai
The 
401 Unauthorized
from 
/api/v1/workload/queue/poll
in the 
workload-launcher
logs means the Workload API Server is rejecting the launcher’s requests because of missing/mismatched auth configuration. From the knowledge sources, similar 401/502/“nothing happens” symptoms are all tied to Workload API authentication: - If 
API_AUTHORIZATION_ENABLED=true
is set, the Workload API expects a specific header + bearer token on all calls. If those are not aligned across components, you get 401s and no pods are launched. [[source-postgres 502](https://github.com/airbytehq/airbyte/issues/65567); [HTTP 500 / 401](https://github.com/airbytehq/airbyte/issues/72826)] - The fix/workaround is to set the same 
WORKLOAD_API_AUTH_HEADER
and 
WORKLOAD_API_BEARER_TOKEN
on all relevant deployments (Workload API Server, Worker, and Workload Launcher). [[source-postgres 502](https://github.com/airbytehq/airbyte/issues/65567); [Connector-sidecar auth bug](https://github.com/airbytehq/airbyte/issues/70451)] For a Kubernetes deployment, the documented workaround is: 1. Generate a token:
Copy code
bash TOKEN=$(openssl rand -hex 24) echo "$TOKEN"
2. Set the same header and token on Workload API Server and Worker (and also Workload Launcher in your case, since it’s the one polling the queue):
Copy code
bash # Namespace example: airbyte-abctl (adjust to your namespace) NAMESPACE=<your-airbyte-namespace>  kubectl -n $NAMESPACE set env deployment/airbyte-abctl-workload-api-server \   WORKLOAD_API_AUTH_HEADER=Authorization \   WORKLOAD_API_BEARER_TOKEN=$TOKEN  kubectl -n $NAMESPACE set env deployment/airbyte-abctl-worker \   WORKLOAD_API_AUTH_HEADER=Authorization \   WORKLOAD_API_BEARER_TOKEN=$TOKEN  kubectl -n $NAMESPACE set env deployment/airbyte-abctl-workload-launcher \   WORKLOAD_API_AUTH_HEADER=Authorization \   WORKLOAD_API_BEARER_TOKEN=$TOKEN
This pattern (same header + same token on all three) is exactly what users used to resolve 401s and 502s when testing connectors. [[source-postgres 502](https://github.com/airbytehq/airbyte/issues/65567); [HTTP 500 / 401](https://github.com/airbytehq/airbyte/issues/72826)] 3. Restart the affected pods (or let the 
set env
rollout restart them), then try “Test connection” again and watch:
Copy code
bash kubectl logs -l <http://app.kubernetes.io/name=workload-launcher|app.kubernetes.io/name=workload-launcher> -n $NAMESPACE --tail=200 -f
If after aligning these env vars you still see 401s, the knowledge sources don’t provide additional, more specific steps for your exact version, so I can’t confidently suggest more than verifying: - 
API_AUTHORIZATION_ENABLED
is set consistently (if enabled) [[Connector-sidecar auth bug](https://github.com/airbytehq/airbyte/issues/70451); [HTTP 500 / 401](https://github.com/airbytehq/airbyte/issues/72826)] - All three deployments have identical 
WORKLOAD_API_AUTH_HEADER
and 
WORKLOAD_API_BEARER_TOKEN
.
t
@kapa.ai I fixed this error. The workload-api-server and workload-launcher were not in the right docker version (their image). But now when I try to retest the source connections I have this error. An idea ? Internal message: Init container error encountered while fetching workload for id: decd338e-5647-4c0b-adf4-da0e75f5a750_806508e1-4137-476e-a2a9-c5ecc1e4dee8_0_check. Encountered exception of type: class com.fasterxml.jackson.module.kotlin.MissingKotlinParameterException. Exception message: Instantiation of [simple type, class io.airbyte.workload.api.client.model.generated.Workload] value failed for JSON property geography due to missing (therefore NULL) value for creator parameter geography which is a non-nullable type at [Source: REDACTED (
StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION
disabled); line: 1, column: 2121] (through reference chain: io.airbyte.workload.api.client.model.generated.Workload["geography"]). Failure origin: airbyte_platform
k
A message from kapa.ai
This error is coming from the workload-init container when it tries to deserialize the 
Workload
object and finds that the 
geography
field is missing/null, but the model now requires it to be non‑nullable: > 
MissingKotlinParameterException ... missing (therefore NULL) value for creator parameter geography which is a non-nullable type ... Workload["geography"]
From the docs, 
geography
is a column on the 
workload
table and is part of the workload model in 1.7/1.8/2.0. [[Config DB workload](https://docs.airbyte.com/platform/1.8/understanding-airbyte/database-data-catalog#workload); [Config DB workload 2.0](https://docs.airbyte.com/platform/2.0/understanding-airbyte/database-data-catalog#workload)] There is also a related issue where a migration to workloads required all connections to have a geography set, otherwise workloads could end up with 
NULL
geography and break things. [[Geography migration note](https://github.com/airbytehq/airbyte/issues/58587)] Putting this together, the most likely cause is: - You now run newer workload components (workload‑api‑server / launcher / init) that expect every workload to have a non‑null 
geography
, - But some existing connections / jobs / workloads in your DB were created without geography, so when the init container fetches the workload JSON, 
geography
is missing and deserialization fails. From the knowledge sources, the recommended direction is: 1. Ensure all connections have a geography set The migration guidance suggests enforcing that “all Airbyte users configure the geography field of ALL Airbyte connections to the geography value of the workspace (
SELECT geography FROM workspace
).” [[Geography migration note](https://github.com/airbytehq/airbyte/issues/58587)] Practically, that means: - In the UI, edit each connection and set its geography to match the workspace geography (EU/US/AUTO), or - At DB level (if you’re comfortable and understand the risk), update any 
NULL
geography values in the relevant tables (connections / jobs / workloads) to a valid geography consistent with your workspace. 2. Check for existing workloads with NULL geography The docs show 
geography
as a column on the 
workload
table. [[Config DB workload](https://docs.airbyte.com/platform/1.8/understanding-airbyte/database-data-catalog#workload)] You’d want to inspect that table and see if there are rows with 
geography IS NULL
for recent workloads (like the failing 
..._check
workload) and update them to a valid value. Because the knowledge sources don’t provide an exact SQL snippet or a step‑by‑step fix for this specific 
MissingKotlinParameterException
in 1.8.2, I can’t safely give you concrete DB commands. But based on the docs and the migration note, the key is: - No workload should have a NULL 
geography
once you’re on the newer workload components. - Align 
geography
on connections/workloads with the workspace geography to unblock the init container. If you’re unsure how to safely patch the DB, the safest path is to: - Set geography via the UI for all connections, - Then re‑try the failing “Test connection” so that a new workload is created with a proper geography.
t
where am I supposed to put that ? I have no field for geography.
@kapa.ai where am I supposed to put that ? I have no field for geography.
k
A message from kapa.ai
You’re right to be confused here—Airbyte’s UI does not expose a “geography” field on connections in 1.8.x, and the knowledge sources don’t document any UI or API field where you can directly set 
geography
for a connection. What we do know from the docs/issues: - 
geography
exists on the 
workspace
 table and on the 
workload
 table in the config DB. [[Workspace table](https://docs.airbyte.com/platform/1.8/understanding-airbyte/database-data-catalog#workspace); [Workload table](https://docs.airbyte.com/platform/1.8/understanding-airbyte/database-data-catalog#workload)] - For multi‑region / Enterprise Flex, you associate a workspace with a region via the 
dataResidency
/ Region setting (UI or 
/v1/workspaces
API). [[Associate region](https://docs.airbyte.com/platform/1.8/enterprise-setup/multi-region#step-3); [Enterprise Flex region](https://docs.airbyte.com/platform/2.0/enterprise-flex/data-plane#step-6)] - A migration issue mentions enforcing that “the geography field of ALL Airbyte connections” should match the workspace geography, but it does not show where that is configured in the product or how to fix it via UI/API. [[Migration comment](https://github.com/airbytehq/airbyte/issues/58587)] There is no explicit documentation in these sources about: - A “geography” field on the connection object in the UI or API. - A supported way to set 
geography
for existing connections to fix this specific 
MissingKotlinParameterException
. Given that, I can’t honestly tell you where to set 
geography
in the product, because the docs and issues you provided don’t show any such field. What is documented and safe to check: 1. Workspace region / data residency Make sure your workspace has a region / data residency set (this is the only geography‑like setting that is documented): - UI: Workspace settings → General → Region. [[Associate region](https://docs.airbyte.com/platform/1.8/enterprise-setup/multi-region#step-3)] - API: 
dataResidency
field on 
/v1/workspaces
(POST/PATCH). [[Enterprise Flex region](https://docs.airbyte.com/platform/2.0/enterprise-flex/data-plane#step-6)] 2. Database fields (only if you’re comfortable and know what you’re doing) The docs show that 
workspace
and 
workload
tables both have a 
geography
column. [[Workspace table](https://docs.airbyte.com/platform/1.8/understanding-airbyte/database-data-catalog#workspace); [Workload table](https://docs.airbyte.com/platform/1.8/understanding-airbyte/database-data-catalog#workload)] The migration comment suggests aligning connection geography with workspace geography, but it does not provide supported SQL or a documented procedure. [[Migration comment](https://github.com/airbytehq/airbyte/issues/58587)] Because of that, I can’t safely give you DB update commands based on these sources. --- So, to answer your question directly: - According to the available docs, there is no user‑visible “geography” field on connections where you can “put that”. - The only documented geography‑like setting is on the workspace (Region / 
dataResidency
). - The error you’re seeing is about an internal 
Workload.geography
field, but the knowledge sources do not document a supported way to set or repair it from the UI or API. Given these limitations, the best next step is: - Verify your workspace Region / 
dataResidency
is set correctly. - If the error persists, you’ll likely need help from Airbyte support or engineering, because fixing 
Workload.geography
for existing workloads/connections is not covered in the public docs you’ve provided.
t
@kapa.ai give me the SQL Query to get the geography parameter in the tables.
k
A message from kapa.ai
The knowledge sources only document where 
geography
exists, not the exact table names for all related objects, so I can only give you queries for the tables that are explicitly described. From the docs, 
geography
is a column on: - 
workspace
[[Workspace table](https://docs.airbyte.com/platform/understanding-airbyte/database-data-catalog#workspace)] - 
workload
[[Workload table](https://docs.airbyte.com/platform/understanding-airbyte/database-data-catalog#workload)] Example SQL (Postgres) to inspect these:
Copy code
sql -- 1) Workspace geography SELECT   id,   name,   geography FROM workspace;  -- 2) Workload geography SELECT   id,   geography,   type,   status,   created_at FROM workload;
The migration comment mentions a 
geography
field on “connections”, but it does not show the table/column name or schema, so I can’t provide a reliable SQL query for that from the given sources. [[Migration comment](https://github.com/airbytehq/airbyte/issues/58587)]
t
@kapa.ai I don't have a geography field on workspace table. But I have one on workload table. They are all set to "AUTO".
k
A message from kapa.ai
Thanks for the extra detail. Based on the docs, 
workload.geography
is indeed a column, but there is no guarantee in the knowledge sources that 
workspace.geography
exists in every deployment/version, so your observation (no 
geography
on 
workspace
, all 
AUTO
on 
workload
) is consistent with what’s documented. [[Workload table](https://docs.airbyte.com/platform/1.8/understanding-airbyte/database-data-catalog#workload)] However, this leaves us with a problem: - Your error says the workload JSON is missing the 
geography
field, but - In the DB, 
workload.geography
is present and set to 
AUTO
for all rows. The knowledge sources do not explain how the 
geography
value is propagated from the DB into the workload JSON, nor do they document any additional place where 
geography
must be configured (e.g., on connections) for 1.8.2. They only mention: - 
geography
column on 
workload
. [[Workload table](https://docs.airbyte.com/platform/1.8/understanding-airbyte/database-data-catalog#workload)] - A migration issue suggesting that all connections’ geography should match the workspace geography, but without any schema/API details for that field. [[Migration comment](https://github.com/airbytehq/airbyte/issues/58587)] Because of that, I cannot reliably tell you: - Why the workload JSON is missing 
geography
even though the DB column is 
AUTO
, or - What exact change (SQL or config) would fix this in your 1.8.2 deployment. Given the limits of the available docs and issues, the only grounded guidance I can offer is: 1. You’ve already confirmed 
workload.geography
is set (all 
AUTO
), which matches the documented schema. [[Workload table](https://docs.airbyte.com/platform/1.8/understanding-airbyte/database-data-catalog#workload)] 2. There is no documented 
geography
field on 
workspace
in your version (and the docs don’t guarantee it for all versions), so you can’t fix this via workspace settings. 3. The public docs do not describe any supported way to repair or override 
geography
for workloads beyond what you’ve already checked. So at this point, with the information in the knowledge sources, I can’t provide a concrete next step that is both accurate and safe (like a specific SQL update or config change) to resolve your 
MissingKotlinParameterException
. You’ll likely need to: - Share this exact error and your findings (no 
workspace.geography
, all 
workload.geography = 'AUTO'
) with Airbyte support or in GitHub/Discuss, so engineering can confirm whether this is a bug in 1.8.2’s workload serialization path and provide a targeted fix or migration script.
t
@kapa.ai even on new connections I have it since I upgraded. Tell me how to fix that when testing a new source or destination. Internal message: Init container error encountered while fetching workload for id: decd338e-5647-4c0b-adf4-da0e75f5a750_2d47b2e7-08ed-4e66-9163-c0cfafa22e9d_0_check. Encountered exception of type: class com.fasterxml.jackson.module.kotlin.MissingKotlinParameterException. Exception message: Instantiation of [simple type, class io.airbyte.workload.api.client.model.generated.Workload] value failed for JSON property geography due to missing (therefore NULL) value for creator parameter geography which is a non-nullable type at [Source: REDACTED (
StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION
disabled); line: 1, column: 2128] (through reference chain: io.airbyte.workload.api.client.model.generated.Workload["geography"]). Failure origin: airbyte_platform
k
A message from kapa.ai
I’m sorry, but the knowledge sources you provided do not contain a documented fix or configuration change for this specific error in 1.8.x: > 
MissingKotlinParameterException ... Workload["geography"] ... missing (therefore NULL) value for creator parameter geography which is a non-nullable type
What we do know from the docs: - The 
workload
table has a 
geography
column (VARCHAR) and in your case it’s already set to 
AUTO
for all rows, which matches the documented schema. [[Workload table](https://docs.airbyte.com/platform/1.8/understanding-airbyte/database-data-catalog#workload)] - The error is thrown when deserializing the Workload API model (Kotlin class) from JSON, not directly from the DB row. The docs do not describe how that JSON is built or any extra place where 
geography
must be configured for new workloads. - A migration comment mentions that connections’ geography should match workspace geography, but it does not document any user‑visible field or supported procedure to set that for new connections. [[Geography migration note](https://github.com/airbytehq/airbyte/issues/58587)] Critically, there is no information in these sources about: - A UI or API field you can set on a new source/destination/connection to satisfy 
Workload.geography
. - A Helm value or environment variable that fixes this 
MissingKotlinParameterException
for new workloads in 1.8.2. - A migration or patch script that updates whatever internal data is causing the workload JSON to be emitted without 
geography
. Because of that, I cannot honestly tell you “do X in the UI/DB/Helm values and it will fix testing new sources/destinations” without guessing beyond the docs. Given the constraints of the available information, the only grounded recommendations are: 1. You’ve already verified 
workload.geography
is non‑NULL (
AUTO
), which matches the documented schema. [[Workload table](https://docs.airbyte.com/platform/1.8/understanding-airbyte/database-data-catalog#workload)] 2. The error still occurs even for new connections after the upgrade, which strongly suggests a bug or mismatch between your upgraded workload components and the rest of the platform, not something you can fix from the UI. 3. There is no documented, supported way in these sources to change how 
geography
is populated into the Workload JSON for new jobs. So, based strictly on the knowledge you’ve provided, I cannot give you a concrete fix for “how to make Test connection work again for new sources/destinations” in 1.8.2. The next step has to be: - Open an issue or support ticket with: - Your Airbyte version and Helm chart version, - The exact error message, - Confirmation that 
workload.geography
is 
AUTO
for new workloads, - And reference the known `geography`/migration discussion so engineering can confirm and provide a targeted patch or migration. [[Geography migration note](https://github.com/airbytehq/airbyte/issues/58587)] Without additional, more specific documentation or an official fix, anything more detailed would be speculation and not aligned with the constraints you set.
2 Views
Open in Slack
PreviousNext
Powered by