I'm getting a yellow "Warning from airbyte_platform: Something went wrong within the airbyte platform." and seeing error "Failed to start sync: An unknown error occurred. (HTTP 409)" when trying to trigger a sync via the airbyte UI (using Core). What's going on? @kapa.ai

Thinking completed HTTP 409 "A sync is already running" Error The HTTP 409 conflict error you're seeing means Airbyte believes a sync is already in progress for that connection, so it refuses to start a new one. This is a known issue reported by multiple users. [Forum Post] Why does this happen? Airbyte enforces that only one sync per connection can run at a time. [Sync Schedules] Sometimes the internal workflow state gets out of sync — for example, a previous sync may have completed successfully but the workflow manager didn't properly register the completion, leaving the connection stuck in a "running" state. [Forum Post] The underlying error looks like:

'message': 'A sync is already running for: <connection-id>'
'exceptionClassName': 'io.airbyte.server.errors.ValueConflictKnownException'

What you can try 1. Wait and refresh — If a sync is genuinely still running (or finishing up), wait a few minutes and check the connection's sync history to see if it completes on its own. 2. Check the connection's sync history in the UI to confirm whether a sync is actually in progress or stuck. 3. Restart Airbyte (if self-hosted) — Restarting the platform can sometimes clear stuck workflow states. 4. Reach out for support — This issue can be tricky to resolve without deeper access to the internal state. The Airbyte community has reported it without a consistent self-service fix. It's recommended to reach out via the Airbyte forum or Slack for further assistance. [Forum Post] > Note: The knowledge sources do not contain a definitive self-service fix for this issue beyond the above steps. If you're on Airbyte Cloud, contacting Airbyte support directly would be the most reliable path. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

In the timeline, it doesn't look like there is a sync running - it looks like many recent syncs have failed with "Activity with activityType='JobFailure' failed: 'Activity task timed out'. scheduledEventId=1038, startedEventId=1039, activityId=dd4181b3-2c7f-3ca8-93ef-b1de59068e31, identity='', retryState=RETRY_STATE_MAXIMUM_ATTEMPTS_REACHED" @kapa.ai

Thinking completed JobFailure Activity Timeout / Maximum Attempts Reached The error you're seeing is a known issue. The

JobFailure

activity is repeatedly hitting Temporal heartbeat timeouts, and after exhausting its retry attempts (

RETRY_STATE_MAXIMUM_ATTEMPTS_REACHED

), the

ConnectionManagerWorkflow

enters a backoff-and-restart loop — which is why the connection appears stuck and new syncs can't be triggered. [Github Issue] What's happening under the hood 1. A sync attempt fails. 2. The

JobFailure

activity is invoked to handle the failure, but it times out (Temporal heartbeat timeout) before completing. 3. After maximum retries of

JobFailure

are exhausted, the workflow waits and then restarts the retry loop — scheduling another attempt for the connection. 4. This cycle repeats, causing the connection to appear perpetually failing/stuck. [Github Issue] The retry backoff progression you'd expect to see in logs looks like: • 10 seconds after the 1st complete failure • 30 seconds after the 2nd • 90 seconds after the 3rd • 4 minutes 30 seconds after the 4th [Sync Jobs Docs] Likely root causes • Worker resource pressure — OOM kills, worker pod restarts, or Temporal connectivity issues can cause heartbeat timeouts on the

JobFailure

activity. • Underlying source/destination connectivity issue — The logs in similar reports show

SOURCE CHECK: Failed

, meaning the source itself may be unreachable, causing repeated failures. [Github Issue] What you can try 1. Check your workers — Look for OOM kills, pod restarts, or resource exhaustion on the Airbyte worker nodes. 2. Check source connectivity — Verify the source connection is reachable (run a manual connection check in the UI). 3. Terminate the stuck workflow (if self-hosted with Temporal access) — You can terminate the specific

ConnectionManagerWorkflow

execution via the Temporal CLI or UI for the

CONNECTION_UPDATER

task queue. This stops the retry loop. [Github Issue] 4. Upgrade Airbyte — A fix has been submitted (PR airbyte-platform#443) that prevents the workflow from restarting when it should be terminating. [Github Issue] > Note: The knowledge sources do not confirm which Airbyte version includes the merged fix. If you're on Airbyte Cloud or need further help, contacting Airbyte support or the community Slack is recommended. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

how do i check my workers? can you give me step by step instructions? I am self hosted but not sure if i have temporal access - can you also give me step by step instructions for this @kapa.ai

Thinking completed I'm sorry, but the knowledge sources do not contain enough detailed step-by-step instructions for checking Airbyte workers or accessing the Temporal UI/CLI in a self-hosted environment to give you a fully reliable guide. What I can share based on the knowledge sources: Checking Workers (Kubernetes) If you're running on Kubernetes, you can exec into pods to inspect them:

# List pods and check their status/restarts
kubectl get pods -n <your-airbyte-namespace>

Look at the RESTARTS column — a high number suggests the worker is crashing (e.g. OOM kills). [Browsing Logs] You can also exec into a specific pod to inspect logs:

kubectl exec -it <pod-name> -n <namespace> -c main bash

Accessing Temporal (Self-Hosted) From a community forum report, one approach attempted was using

tctl

pointed at the Temporal pod IP:

TEMPORAL_CLI_ADDRESS=<temporal_pod_ip>:7233 tctl admin wf describe --workflow_id "<workflow_id>"

However, this approach had connectivity issues reported in practice (especially with Cloud SQL proxy setups). [Forum Post] > I'd strongly recommend: > 1. Checking the Airbyte Community Slack at slack.airbyte.com for hands-on help. > 2. If you're on a paid plan, opening a support ticket — especially for Temporal workflow termination, which carries risk if done incorrectly. > Can you tell me more about your deployment? (e.g. Docker Compose vs Kubernetes, cloud provider) — that would help narrow down the right approach. 👍 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 when trying to test a source, I get error "Airbyte is temporarily unavailable. Please try again. (HTTP 502)"

Thinking completed HTTP 502 Error When Testing a Source This is a known issue affecting self-hosted Airbyte installations (both

abctl

and Kubernetes deployments). Based on the knowledge sources, the root cause is typically a missing or mismatched bearer token between the

worker

and

workload-api-server

services. [Github Issue] You can confirm this by checking your worker logs for:

java.lang.RuntimeException: io.airbyte.api.client.ApiException: Unauthorized

Fix (inside your Airbyte container or cluster) A community-confirmed working solution is to manually generate and apply a matching auth token to both services. [Github Issue] Step 1 — If using Docker (

abctl

), get into the container first:

docker ps
# Find your container ID, then:
docker exec -it <containerID> bash

Step 2 — Generate and apply matching auth tokens:

# Generate a token
BEARER_TOKEN=$(openssl rand -hex 16)
echo "Generated token: $BEARER_TOKEN"

# Apply to both deployments
kubectl -n airbyte-abctl set env deployment/airbyte-abctl-worker \
  WORKLOAD_API_BEARER_TOKEN="$BEARER_TOKEN" \
  INTERNAL_API_AUTH_TOKEN="$BEARER_TOKEN"

kubectl -n airbyte-abctl set env deployment/airbyte-abctl-workload-api-server \
  WORKLOAD_API_BEARER_TOKEN="$BEARER_TOKEN"

Step 3 — Restart both services:

kubectl -n airbyte-abctl rollout restart deployment airbyte-abctl-worker
kubectl -n airbyte-abctl rollout restart deployment airbyte-abctl-workload-api-server

Step 4 — Wait for rollouts to complete:

kubectl -n airbyte-abctl rollout status deployment airbyte-abctl-worker
kubectl -n airbyte-abctl rollout status deployment airbyte-abctl-workload-api-server

After this, try testing your source again. [Github Issue] > Note: If your namespace is different from

airbyte-abctl

(e.g. a custom Helm deployment), replace it accordingly. You can check your namespace with

kubectl get namespaces

. 👍 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 In additon to the above source error, I'm getting a destination error: "Could not connect with provided configuration. Error: Database connection failed. Please verify the host and port are correct and the server is reachable. State code: 08001;". could these two things together point to a different root cause?

Thinking completed Destination Connection Error + 502 Source Error Together The combination of these two errors is interesting. Let me break down what each one means and whether they share a root cause. The Destination Error (State code: 08001) The

08001

SQL state code means the database connection was refused — the host/port is unreachable. The error message you're seeing is the user-friendly version of this: [Github Code]

Database connection failed. Please verify the host and port are correct 
and the server is reachable. State code: 08001;

Do They Share a Root Cause? Possibly yes — but it depends on your setup. There are two likely scenarios: Scenario A: The 502 is masking the real destination error If the

workload-api-server

/ worker auth token issue (the 502 root cause) is not fully resolved, both source tests and destination tests could fail — the 502 for sources and a misleading connectivity error for destinations — because the workers can't properly execute connector checks at all. Fix the 502 first (as described above) and then re-test your destination. [Github Issue] Scenario B: Genuine destination connectivity issue The

08001

error is a real network-level refusal. Common causes include: • Using

localhost

or

127.0.0.1

as the host — this resolves to the container itself, not your actual database host, when running inside Docker/Kubernetes. [Forum Post] • A firewall or security group blocking inbound traffic from Airbyte to your database. • Wrong port configured. Recommended Order of Action 1. First, apply the bearer token fix for the 502 error (as described in the previous step). 2. Then re-test both source and destination fresh. 3. If the destination error persists, verify: ◦ You are not using

localhost

or

127.0.0.1

as the host — use the actual hostname or IP reachable from within the Airbyte cluster. ◦ The database port is open and accessible from Airbyte's network. ◦ If on Airbyte Cloud, that your database allows Airbyte's IP addresses. [Github PR] > In short: Fix the 502 first — it may be causing both errors. If the destination error remains after that, it's a genuine network connectivity issue independent of the platform problem. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

What if i told you i am also getting a source error on a SQL server source? Could not connect with provided configuration. Error: SQL Server Connection Error: The sync encountered a network connection issue while connecting to the SQL Server, will retry. docs.microsoft.com/en-us/…/troubleshooting-connectivity @kapa.ai

Thinking completed SQL Server Source Connection Error — A Clearer Picture This is actually very helpful context. The SQL Server error you're seeing maps directly to a known pattern in the source-mssql connector code: Regex rule match:

(?i).*the tcp\/ip connection to the host.*has failed.*

Classified as:

transient

(network-level, will retry) [source-mssql config] Or alternatively, JDBC error code 2 (SQL Server network error) triggers the same message. [source-mssql config] This Changes the Picture Significantly You now have three connectivity failures across different connectors: • HTTP 502 on source tests (platform-level) • Destination

08001

— host unreachable • SQL Server source — TCP/IP connection failed The fact that both your source and destination connectors are failing with network-level errors strongly suggests the root cause is not the bearer token / 502 platform issue — or at least not only that. It points more toward a broader network connectivity problem between your Airbyte workers and your external services. Things to Check 1. Fix the 502 first — Apply the bearer token fix as described earlier. Without this, you can't trust any connection test results at all. [Github Issue] 2. After fixing the 502, re-test everything. If the SQL Server and destination errors persist, investigate: ◦ Are you using

localhost

or

127.0.0.1

as the host for either? These won't work inside a container. ◦ Are your SQL Server and destination database hosts reachable from within the Airbyte pod/container network? ◦ Do your firewall/security group rules allow inbound connections from Airbyte's IP addresses? 1. Note on the SQL Server error wording — There is actually an open PR (#88496) specifically to fix the misleading "will retry" wording on connection tests, since no retry actually happens during a connection test. The improved message would read: [Github PR] Airbyte could not reach the SQL Server host and port provided. Check that the host and port are correct, that the SQL Server instance accepts remote TCP/IP connections, and that your firewall or security group allows inbound connections from Airbyte's IP addresses.This is a more accurate description of what's likely happening. > In summary: The pattern of failures across multiple connectors suggests a network-level issue in your Airbyte deployment rather than individual connector misconfigurations. Resolve the 502 platform issue first, then verify your Airbyte workers have proper network access to your external hosts. 👍 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 restarting the airbyte server seems to have fixed all of these problems - no other action was necessary.

Thinking completed Great News! That's a useful data point. A simple restart resolving all of these issues simultaneously — the 502 errors, the source connection failures, and the destination connectivity error — strongly suggests the root cause was a transient platform state issue rather than any genuine network or configuration problem. Things like: • Stuck or degraded worker processes • Internal service communication failures (e.g. between worker and workload-api-server) • Temporal workflow state getting out of sync ...can all manifest as seemingly unrelated errors across the UI, but clear up when the platform is restarted fresh. Takeaway for the Future If you see a cluster of unrelated-looking errors across multiple connectors and platform components at the same time, a restart is a reasonable first troubleshooting step before diving deeper into individual error messages. The errors can be misleading when the underlying issue is platform-level instability. Glad it's working! If the issues return, feel free to come back and we can dig deeper. 👍 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.