@kapa.ai Is there any update on this issue? We just redeployed our production instance and are now stuck as the bootloader will not run. https://github.com/airbytehq/airbyte/issues/75614

I don't have any information about the specific GitHub issue #75614 in my knowledge sources, so I can't provide an update on that particular thread. However, based on related issues in my knowledge sources, here are some known causes and troubleshooting steps for bootloader failures: Known Causes of Bootloader Failures 1. Cannot connect to the database – The most common cause is the bootloader being unable to reach

airbyte-db-svc

. [Troubleshooting abctl] 2. Duplicate key in remote connector registry – A recently reported issue (as of ~March 30, 2026) where

source-sap-hana

and

source-sap-hana-enterprise

share the same

sourceDefinitionId

, causingjava.lang.IllegalStateException Duplicate key b6935898-aadb-46ae-99ca-d697207994c1This blocks all new installations since the bootloader fetches the live remote registry at startup, regardless of chart version. [bootloader failed issue] Troubleshooting Steps 1. *Check bootloader logs:*kubectl logs airbyte-abctl-bootloader -n airbyte-abctl --kubeconfig /root/.airbyte/abctl/abctl.kubeconfig 2. *Verify the database pod is running:*kubectl get pods -n airbyte | grep db 3. *Check the database service and endpoints:*kubectl get svc airbyte-db-svc -n airbyte kubectl get endpoints airbyte-db-svc -n airbyte 4. Try restarting the bootloader pod after confirming the DB is healthy:kubectl delete pod -n airbyte -l app.kubernetes.io/name=bootloader[pod bootloader failed] I'd recommend checking the bootloader logs first — they should reveal the specific error. You can also join the Airbyte Community Slack for peer support or open a support ticket if you're an Airbyte Cloud customer. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

It is the duplicate keys in the remove connector registry. Could we downgrade

Unfortunately, downgrading the chart version will not help in this case. As noted in the related issue, the bootloader fetches the live remote registry at startup regardless of which chart version you're running: > "Pinning to an older chart version (2.0.18) doesn't help since the bootloader fetches the live remote registry at startup regardless of chart version." [bootloader failed issue] Root Cause The live OSS registry at

https://connectors.airbyte.com/files/registries/v0/oss_registry.json

contains two duplicate entries for the SAP HANA connector with the same UUID (

b6935898-aadb-46ae-99ca-d697207994c1

). This causes Java's

Collectors.toMap()

to throw an

IllegalStateException

, preventing the bootloader from starting. [Duplicate Live Registry Value] What You Can Do Based on the knowledge sources, there is no user-side workaround for this issue: > "Unfortunately there is no user-side workaround for this since the issue is in the remotely-fetched registry. The fix needs to happen server-side by removing the duplicate entry from the published registry." [Duplicate Live Registry Value] The Airbyte engineering team has been made aware and is tracking it internally. Your best options right now are: 1. Monitor the GitHub issue #75614 for updates on when the registry is fixed. 2. Join the Airbyte Community Slack for real-time updates. 3. Open a support ticket at support.airbyte.com if you're an Airbyte Cloud customer, referencing the issue URL. 👍 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 I increased the minio PVC and this triggered a reload, but is there a way to just bring things online without having the bootloader run?

Based on the knowledge sources, there is one approach mentioned for bypassing the bootloader — disabling it in the Helm values:

airbyte-bootloader:
  enabled: false
  image:
    repository: airbyte/bootloader
    pullPolicy: IfNotPresent

One user reported using this approach to get past repeated bootloader failures during Helm chart changes. [EKS installation issue] However, I want to be transparent about the limitations of this advice: • The knowledge sources don't provide full details on the risks or side effects of disabling the bootloader in your specific scenario. • The bootloader is responsible for database migrations and initialization, so disabling it could cause issues if any schema migrations are pending. • This was mentioned as a workaround by a community user, not as an officially recommended approach. Given that your instance was previously running and you're just recovering from a PVC resize (not a version upgrade), the risk of missing a migration may be lower — but I cannot confirm this from the available knowledge sources. I'd strongly recommend: 1. Monitoring GitHub issue #75527 and #75614 for a fix to the duplicate registry entry, which is the actual root cause. 2. Reaching out on Airbyte Community Slack for guidance from the engineering team before disabling the bootloader in production. 👍 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 could I just restart some of the pods to get it back in sync with th ePVC

Sorry @Kevin O'Keefe, I'm currently experiencing some technical difficulties. Please try again in a few minutes. If this issue persists, please reach out to the administrators of this Slack workspace.

@kapa.ai could I just restart some of the pods to get it back in sync with th ePVC

Based on the knowledge sources, there is one relevant example of restarting pods to resolve sync/availability issues:

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

This was reported to resolve a 502 error issue for one user. [HTTP 502 issue] However, I want to be clear about the limitations here: the knowledge sources don't specifically address restarting pods to resync after a PVC resize. The core problem in your case is still the duplicate registry entry causing the bootloader to fail — restarting other pods won't resolve that underlying issue, and if the bootloader is still failing, other pods that depend on it completing successfully may not function correctly either. The bootloader pod itself can be restarted with:

kubectl delete pod -n airbyte -l app.kubernetes.io/name=bootloader

[pod bootloader failed] But again, this won't help until the duplicate registry entry is fixed on Airbyte's side. I'd recommend continuing to monitor GitHub issue #75614 for a server-side fix, as that remains the root cause. 👍 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 is there a way for you to notify me when it is resolved?

Unfortunately, I'm not able to send you notifications or alerts — I'm an AI assistant without the ability to monitor external resources or proactively reach out to you. To get notified when the issue is resolved, here are some options: 1. Watch the GitHub issue directly — On GitHub issue #75614, click the Subscribe button to receive email notifications when there are updates. 2. Join the Airbyte Community Slack — You can follow relevant channels for real-time updates from the community and Airbyte team. 3. Open a support ticket at support.airbyte.com if you're an Airbyte Cloud or enterprise customer, referencing the issue URL so the team can follow up with you directly. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.