@kapa.ai Failure in source: Exhausted available request attempts. Please see logs for more details. Exception: Gmail returned a per-user or per-project quota saturation 403 (rateLimitExceeded / userRateLimitExceeded). Honouring

Retry-After

and retrying — the sync will resume once Gmail’s rolling quota window frees up. how to increase limit

Thinking completed The provided knowledge sources do not explicitly describe how to request or apply a quota increase directly in Google Cloud for the Gmail API. However, based on the documentation, you can prevent exhausting your quota limits by adjusting the connector configuration: 1. Reduce the number of concurrent workers The Gmail connector consumes quota units rapidly because substreams like

messages_details

and

threads_details

make a

get

call per record [Gmail Documentation]. If you see rate limit errors or backoff exhaustion, reduce the Number of concurrent workers (

num_workers

) setting in your Gmail source configuration [Gmail Documentation; Gmail Documentation]: • By default, this is set to

5

[Gmail Documentation]. • Lowering this value reduces parallel requests and keeps the sync within Gmail's per-minute quota limits [Gmail Documentation; Gmail Documentation]. 2. General Google Cloud Quotas While specific increase steps for Gmail are not detailed in the sources, Google API quotas generally reside within your project's APIs & Services > Quotas section in the Google Cloud Console [GA4 Contributing Guide; GSC Documentation]. Note that Gmail enforces hard limits of: • Per-project rate limit: 1,200,000 quota units per minute [Gmail Documentation] • Per-user rate limit: 15,000 quota units per minute per user [Gmail Documentation] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

what permisison to give to sservice account of GCP @kapa.ai to create seceret and manage it,

Thinking completed The knowledge sources list the Google Secret Manager roles for the GCP service account used when installing Airbyte. They don't give a dedicated policy for the external secrets feature on GCP. Roles for Google Secret Manager Grant the service account these roles so it can create, read and manage secrets: [GCP Infrastructure]

roles/secretmanager.secretAccessor
roles/secretmanager.secretVersionAdder
roles/secretmanager.secretVersionManager
roles/secretmanager.viewer

Optional: Google Cloud Storage roles If you also use Google Cloud Storage, the same page lists these roles: [GCP Infrastructure]

roles/storage.objectCreator
roles/storage.admin

Notes • Airbyte's External Secret Management guide, available for Pro and Enterprise Flex plans, doesn't include a GCP policy. It tells you to contact your Airbyte representative for GCP setup guidance and policy documentation. [External Secrets] • The knowledge sources don't say whether the roles above fully match what that feature requires. If you are using it, confirm with your Airbyte representative. • The GCP page covers creating the service account itself, with a link to Google's documentation. [GCP Infrastructure] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

have airbyte 1.6.2 and all the passowrd are in Db i want to move all in GCP secret and goinf forward that should be refreed and remove the password from the DB. new password will be added there and old will use the secret. @kapa.ai

Thinking completed I'm sorry, but the knowledge sources don't describe a way to migrate existing connector passwords from the Airbyte database into GCP Secret Manager, or to remove them from the database afterwards. They also don't say anything specific to version 1.6.2. What the sources do say • Default behavior: Airbyte stores connector secrets in the configured database in plain text. It recommends an external secret manager, and Google Secret Manager is supported. New connectors write and read secrets from the configured manager. [Secret Management] • Existing connectors will fail: Changing the connector secret storage configuration causes all existing connectors to fail. You must recreate them so they read from the new secret store. [Secret Management Values] • Helm configuration for GCP: Create a Kubernetes secret with your service account JSON (default key

gcp.json

). Then set this in `values.yaml`: [Secret Management Values]

global:
  secretsManager:
    type: GOOGLE_SECRET_MANAGER
    secretName: "airbyte-config-secrets" # Name of your Kubernetes secret.
    googleSecretManager:
      projectId: <project-id>
      region: "" ## Optional - e.g. us-central1
      credentialsSecretKey: gcp.json

• Referencing existing secrets: Newer versions let you reference a secret that already exists in your manager using the

secret_coordinate::<secret-name>

prefix in a connector's secret fields. This is an Enterprise feature (Pro and Enterprise Flex). It works through the API or Terraform, and Airbyte resolves the value at runtime. [External Secret References] The sources don't confirm whether it is available in 1.6.2. Practical implication Based on the sources, the supported path is: 1. Configure Google Secret Manager as above. 2. Recreate each existing connector, re-entering its password, so the secret is written to GCP. 3. Create new connectors the same way. The sources don't describe a bulk migration tool, and they don't say how to clear the old plain-text values from the database. For those, I'd suggest checking with your Airbyte representative or support. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

ok how to migrate @kapa.ai

Thinking completed I'm sorry, but the knowledge sources don't describe a migration procedure or a bulk migration tool for moving existing connector passwords from the Airbyte database into GCP Secret Manager. They also don't explain how to remove the old values from the database, and they say nothing specific to version 1.6.2. What the sources support 1. Create a Kubernetes secret with your GCP service account JSON, by default under the key

gcp.json

in

airbyte-config-secrets

. [Secret Management Values] 2. Configure Helm values to use Google Secret Manager: [Secret Management Values]

global:
  secretsManager:
    type: GOOGLE_SECRET_MANAGER
    secretName: "airbyte-config-secrets" # Name of your Kubernetes secret.
    googleSecretManager:
      projectId: <project-id>
      region: "" ## Optional - e.g. us-central1
      credentialsSecretKey: gcp.json

3. Recreate existing connectors. Changing the secret storage configuration causes all existing connectors to fail, so you must recreate them to read from the new store. Re-enter each password when recreating, so it is written to GCP. [Secret Management Values] 4. Make sure the service account has the needed roles:

roles/secretmanager.secretAccessor

,

secretVersionAdder

,

secretVersionManager

and

viewer

. [GCP Infrastructure] Rotation and referencing existing secrets If you already have secrets in your manager, Pro and Enterprise Flex plans can reference them with the

secret_coordinate::<secret-name>

prefix via the API or Terraform. This lets you rotate secrets in the manager without updating connector configurations. [External Secret References] The sources don't confirm whether this is available in 1.6.2. For a bulk migration and for cleaning passwords out of the database, I recommend contacting Airbyte support or your Airbyte representative. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

Version : Database version is supported by dialect POSTGRES: 16.15 2026-10-13 204031,152 [main] ERROR i.a.i.InputFetcher(failWorkloadAndExit):59 - Init container error encountered while processing workload for id: 36c891d9-4bd9-43ac-bad2-10e12756272c_017be116-eb85-46db-a9ab-92acd2a53433_0_check. Attempting to fail workload... java.lang.NullPointerException: Cannot invoke “java.util.UUID.toString()” because the return value of “io.airbyte.persistence.job.models.IntegrationLauncherConfig.getConnectionId()” is null at io.airbyte.initContainer.input.CheckHydrationProcessor.process(CheckHydrationProcessor.kt:52) @kapa.ai

Thinking completed I'm sorry, but the knowledge sources don't mention this

NullPointerException

in

CheckHydrationProcessor

, so I can't confirm its cause or a fix. What the sources do show • The workload ID ends in

_check

, so this is a check workload (for example, testing a connector configuration). The error comes from the

init

container of the check pod. [Container Reference] • The

init

container only emits workload initialization logs. In check, discover and spec pods, the

sidecar

container holds the relevant output. [Container Reference] • The stack trace says

getConnectionId()

returned null. The sources don't explain why. Check workloads for a new or unsaved source may not have a connection, but I can't confirm that from the sources. Suggested debugging steps The sources describe these steps for workload failures: [Workload Monitor] 1. Check pod status:

kubectl get pods -n <namespace>

2. Inspect pod events:

kubectl describe pod <pod-name> -n <namespace>

3. Review pod logs:

kubectl logs <pod-name> -n <namespace> -c <container-name>

Context You are on Airbyte 1.6.2 and were changing secret storage to GCP Secret Manager. Changing that configuration makes existing connectors fail until they are recreated. [Secret Management Values] The sources don't link this error to that change, so I can't say whether it is related. If the error persists, I recommend opening an issue with Airbyte support or on GitHub, including the full init container log and your Airbyte version. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.