https://linen.dev logo
Join Slack
Powered by
<@U04S8PLJWMT> We are trying to set up Airbyte OSS...
# replication-ask-ai
j
@kapa.ai We are trying to set up Airbyte OSS 2.0.1. when I save a source or destination I get
Copy code
Failed to save Salesforce due to the following error: errors.http.default
We are using S3 for storage and I have verified that the credentials are valid and work. The feedback I am seeing is that something is not configured properly for temporal. We did not make any changes to the default settings in the values.yaml. Can you provide guidance on how to troubleshoot / fix this?
k
The knowledge sources you provided don’t contain any direct documentation or examples for the specific error message: > 
Failed to save Salesforce due to the following error: errors.http.default
in Airbyte OSS 2.0.1, nor do they describe Temporal-related misconfiguration symptoms for this case. I can only give partial, high‑level guidance based on what is documented. From the docs, the main configuration area that can affect saving sources/destinations in OSS 2.x in your setup is storage (since you’re using S3) and, separately, connector‑level HTTP error handling. 1. Re‑check S3 storage configuration For OSS 2.x on Kubernetes, the 
values.yaml
for storage should follow this pattern for S3: [State & logging]
Copy code
global:
  storage:
    type: "S3"
    secretName: airbyte-config-secrets # or your secret name
    bucket:
      log: airbyte-bucket
      state: airbyte-bucket
      workloadOutput: airbyte-bucket
    s3:
      region: "us-east-1"              # e.g.
      authenticationType: credentials  # or instanceProfile
      accessKeyId: ""                  # if using credentials
      secretAccessKey: ""              # if using credentials
Key things to verify against the docs: • 
type
is exactly 
"S3"
(case‑sensitive). [State & logging] • 
authenticationType
is either 
credentials
or 
instanceProfile
and matches how your cluster is actually authorized. [State & logging] • If using 
credentials
, the access key and secret key are either: ◦ set directly in 
values.yaml
, or ◦ provided via the Kubernetes secret referenced by 
secretName
under the keys 
s3-access-key-id
and 
s3-secret-access-key
. [State & logging] • If using 
instanceProfile
, ensure the node/role really has S3 permissions for the specified bucket(s). [State & logging] Even if you’ve validated the credentials themselves, a mismatch between 
authenticationType
, 
secretName
, or key names in the secret can still cause storage‑related HTTP failures when Airbyte tries to persist configs or logs. 2. Confirm Salesforce connector configuration The Salesforce source/destination setup itself is standard OAuth 2.0. For OSS, you must provide 
Client ID
, 
Client Secret
, and 
Refresh Token
manually for the source, and similarly for the destination. [Salesforce source setup; Salesforce dest setup] Check: • “Is Sandbox” matches your actual Salesforce environment; changing it requires re‑auth. [Salesforce source setup; Salesforce dest config] • Client ID/Secret are copied exactly from the Connected App. [Salesforce dest troubleshooting] • The refresh token is valid; if in doubt, re‑run the OAuth flow and obtain a new one. [Salesforce dest troubleshooting] However, the docs do not state that misconfigured Salesforce credentials would surface specifically as 
errors.http.default
when saving the connector, so this may or may not be the root cause. 3. About Temporal / internal HTTP errors The provided docs do not describe: • how Temporal is wired in OSS 2.0.1, or • how 
errors.http.default
is generated or mapped from Temporal / internal services. They also don’t give a prescribed troubleshooting path for this exact error. I therefore cannot reliably tell you which Temporal setting to change or which internal service is failing. 4. What you can do next Given the limitations of the docs: 1. Double‑check your 
values.yaml
against the S3 examples above, and verify the Kubernetes secret contents and key names. [State & logging] 2. Re‑validate your Salesforce connector configuration (sandbox flag, OAuth credentials, refresh token). [Salesforce source setup; Salesforce dest troubleshooting] 3. If the issue persists, you’ll likely need to inspect pod logs (webapp, server, Temporal, and any worker pods) to see the underlying HTTP error behind 
errors.http.default
. Unfortunately, the exact log messages and remediation steps are not covered in the knowledge sources you shared. Because the documentation and issues you provided don’t go into this specific error path, I can’t give a more precise Temporal‑level fix without going beyond the available information. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
The knowledge sources don’t contain anything specific about the 
errors.http.default
message when saving a Salesforce source/destination in OSS 2.0.1, nor about a known Temporal misconfiguration in that version, so the guidance below is necessarily limited. From what is documented: 1. Confirm S3 storage is configured via Helm values, not only via env vars For OSS 2.x on Kubernetes/Helm, Airbyte’s internal storage (logs, state, workload output) must be configured under 
global.storage
in 
values.yaml
, including the S3 auth method. Example for Helm v2 charts: [2.0 storage]
Copy code
global:
     storage:
       type: "S3"
       secretName: airbyte-config-secrets
       bucket:
         log: airbyte-bucket
         state: airbyte-bucket
         workloadOutput: airbyte-bucket
       s3:
         region: "us-east-1"          # your region
         authenticationType: credentials  # or instanceProfile
         accessKeyId: ""              # if using credentials
         secretAccessKey: ""          # if using credentials
If you’re using instance profiles, set 
authenticationType: instanceProfile
and omit the keys. [2.0 storage] Misconfigured internal storage can surface as generic HTTP errors when the platform tries to persist configs or logs. 2. Check for conflicting AWS env vars There is a prior report where Helm-based deployments had issues due to conflicting 
AWS_ACCESS_KEY_ID
/ 
AWS_SECRET_ACCESS_KEY
env vars on the server pod; the same setup worked when deployed via Kustomize. [Forum S3 env] As a test: ◦ Inspect the 
airbyte-server
(or equivalent) pod env. ◦ If you see 
AWS_ACCESS_KEY_ID
/ 
AWS_SECRET_ACCESS_KEY
set at the pod level, try removing them from your Helm values / deployment and rely solely on the 
global.storage
configuration (or instance profile). 3. Verify S3 credentials independently A separate S3 issue notes that many S3 problems are credential/config related and recommends validating credentials outside Airbyte. [S3 issue] You’ve already confirmed they work, but double‑check: ◦ The access key is active. ◦ No typos / whitespace. ◦ The IAM principal has permissions for the exact bucket(s) configured under 
global.storage.bucket.*
. 4. Workload / sidecar configuration (if using v2 workload API) There is an open issue in 2.0.1 OSS where connector sidecars cannot authenticate to the workload API server because 
WORKLOAD_API_AUTH_HEADER
and 
WORKLOAD_API_BEARER_TOKEN
are not propagated correctly, causing 401s and UI timeouts when testing connections. [Workload API issue] In that report, the user had:
Copy code
workloadApiServer:
     extraEnv:
       - name: AWS_DEFAULT_REGION
         value: "us-east-2"
       - name: AWS_REGION
         value: "us-east-2"
       - name: STORAGE_REGION
         value: "us-east-2"
       - name: S3_REGION
         value: "us-east-2"
       - name: WORKLOAD_API_AUTH_HEADER
         value: "Authorization"
       - name: WORKLOAD_API_BEARER_TOKEN
         value: "[generated-token]"
And the ConfigMap contained:
Copy code
WORKLOAD_API_SERVER_ENABLED=true
   WORKLOAD_API_HOST=http://airbyte-workload-api-server-svc.airbyte-v2:8001
   STORAGE_TYPE=s3
   STORAGE_BUCKET_LOG=...
   STORAGE_BUCKET_STATE=...
   STORAGE_BUCKET_WORKLOAD_OUTPUT=...
   STORAGE_BUCKET_AUDIT_LOGGING=...
   STORAGE_BUCKET_ACTIVITY_PAYLOAD=...
If your deployment is similar, it’s possible you’re hitting the same underlying issue, which can manifest as failures when saving/testing connectors. The GitHub issue is still open and does not document a definitive workaround. 5. Salesforce‑specific checks For Salesforce itself, the docs only cover standard OAuth and common auth errors (invalid client, refresh token, sandbox vs production mismatch). [SF config; SF troubleshooting] Since your error is a generic 
errors.http.default
at save time (not a clear Salesforce OAuth error), it’s more likely platform‑level (Temporal / storage / workload API) than Salesforce config. ------------------------- Because the knowledge sources don’t include Temporal‑specific configuration for 2.0.1 or a direct mapping from 
errors.http.default
to root cause, I can’t give a precise Temporal fix. Based on what is documented, the most concrete next steps are: 1. Ensure 
global.storage
for S3 is correctly set in 
values.yaml
(including 
authenticationType
and region) and that the referenced secret exists and contains the right keys. [2.0 storage] 2. Remove any global 
AWS_ACCESS_KEY_ID
/ 
AWS_SECRET_ACCESS_KEY
env vars from the server/worker pods and rely on the Helm storage configuration or instance profile. [Forum S3 env] 3. Compare your workload API / sidecar configuration with the known 2.0.1 OSS issue to see if you’re affected by the same bug. [Workload API issue] If after these checks the error persists, the next step would be to share pod logs (server, worker, workload‑api‑server) and your sanitized 
values.yaml
in a GitHub issue or the forum, since the current knowledge sources don’t provide a documented resolution for this exact combination of symptoms. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
2 Views
Open in Slack
PreviousNext
Powered by