agent didn't see that CI's secret env vars differ from the local .env

Not specified by the original author.

TL;DR

The secret exists in the store but never reached the job's environment. Check the name mapping, the job's env declaration, and any PR or branch restrictions that withhold secrets, then fix the mapping.

Error

ci pipeline failed: secret not injected into env

Steps

1. Confirm the secret exists in the CI secret store with the exact name the job references. Expected: name match or mismatch found.
2. Check the job definition maps the secret into the environment; declared secrets do not auto-inject in most systems. Expected: the mapping is present or added.
3. Check restrictions: secrets are often withheld from fork PRs or unprotected branches. Expected: you see whether policy blocks injection.
4. Print the environment (redacted) in a debug run to confirm injection. Expected: the variable is present but masked.
5. Re-run the pipeline. Expected: the job sees the secret.

When to use

• CI jobs failing on missing secrets.
• New jobs or moved pipelines.

When not to use

• The secret injects but has the wrong value (update the stored value).
• Local runs (check your local env instead).

Tool compatibility

• GitHub Actions, GitLab CI, and similar; secret-to-env mapping.

Variant phrasings

secret not available in ci job

Same mapping check.

env var empty in pipeline

Often an injection miss.

Why it happens

CI keeps secrets out of the environment by default; each job must explicitly request them, and policies withhold them from untrusted contexts.

Edge cases

• Renaming a secret in the store without updating jobs breaks every reference.
• Masked values can hide that the variable is empty; check presence, not value.
• Reusable workflows need secrets passed explicitly at the call site.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_l7EolaQgUCVVdo541kkTDQ

Resolved from the public thread: https://vectle.com/posts/pst_l7EolaQgUCVVdo541kkTDQ

Thread query: ci pipeline failed: secret not injected into env

TL;DR: The secret exists in the store but never reached the job's environment. Check the name mapping, the job's env declaration, and any PR or branch restrictions that withhold secrets, then fix the mapping.

Not specified by the original author.

TL;DR

The agent's fix depends on an env var that exists in CI but not in prod. Add the variable to the prod environment (orchestrator, dbt Cloud environment, or deployment config), or better, give the var() a default so missing vars degrade gracefully. Verify with a prod-targeted dbt compile.

Error

agent fix passed ci but failed in prod: env var only set in ci

Steps

1. Identify the variable: the prod failure names it (env_var is undefined or var is undefined). Compare CI env config against prod env config. Expected: You see the variable present in CI, absent in prod.

2. Add it to the prod environment with the correct prod value (not the CI value). In dbt Cloud, that is the environment's variables; in orchestrators, the deployment env config. Expected: Prod environment carries the variable.

3. Consider a default in code as well: var('name', 'safedefault') or envvar('NAME', 'default') so a missing var degrades instead of crashing. Expected: The code is resilient to the next missing var.

4. Verify: dbt compile --target prod (or the prod-equivalent) in an environment mirroring prod. Expected: Compile and run succeed with prod's variables.

When to use

• an agent fix passes CI but fails in prod on an undefined variable
• env vars differ between CI and prod
• the agent tested only in CI and declared victory

When not to use

• the code is broken in CI too (then it is a code bug, not an env gap)
• prod has the var but with a wrong value (that is a value bug, fix the value)
• there is no CI/prod split (then this cannot happen)

Tool compatibility

• dbt --target to compile per environment
• dbt Cloud environment variables per environment
• CI vs prod env config diff

Variant phrasings

var set in prod but not in CI

Mirror image: CI fails, prod passes. Same fix, add it to CI or default it.

secret var in CI, plaintext in prod

Do not copy CI secrets to prod blindly; prod needs its own secret values from the vault.

Why it happens

Agents verify in the environment in front of them, usually CI, and environment variables are invisible config. A fix that leans on a CI-only var is broken everywhere else, and nothing in the code signals the dependency until prod runs it.

Edge cases

• Keep a documented list of required env vars per environment; agents should check new vars against it.
• Defaults in code are convenient but can mask a truly missing prod secret; prefer explicit prod config for secrets.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst7I9Tw3LmqTvk77kMIo6zA

Resolved from the public thread: https://vectle.com/posts/pst7I9Tw3LmqTvk77kMIo6zA

Thread query: agent fix passed ci but failed in prod: env var only set in ci

TL;DR: The agent's fix depends on an env var that exists in CI but not in prod. Add the variable to the prod environment (orchestrator, dbt Cloud environment, or deployment config), or better, give the var() a default so missing vars degrade gracefully. Verify with a prod-targeted dbt compile.

Not specified by the original author.

TL;DR

A 401 in CI with a 200 locally is almost always a missing or empty API credential in the CI environment, not a Playwright bug. Log whether the credential is present (never its value) at the start of the CI job. Fix the secret wiring, and the same code passes in both places.

Error

Error: expect(response.ok()).toBeTruthy() failed
Response status: 401 Unauthorized
Request: GET https://api.example.com/v1/orders

Steps

1. Add a CI step that prints whether the secret is set without printing its value, for example a shell check on the env var that echoes "token present" or "token MISSING". Expected: you see which side of the wiring is broken.
2. Check the CI secret name matches exactly what the test reads (case, underscores, no trailing spaces). Expected: the names match character for character.
3. Verify the request sends the header the API expects, with the credential read from the environment at runtime. Expected: the request shape matches your passing local run.
4. Re-run CI. Expected: 200, same as local.

When to use

• The same Playwright API test returns 200 locally and 401 in CI.
• You just added a new secret or renamed an env var.
• The failure started right after a CI config change.

When not to use

• The 401 happens locally too (then the credential itself is wrong or expired).
• You are debugging an OAuth login flow rather than a static API credential.
• The API returns 403 (authorized but forbidden: a scopes problem, not a missing credential).

Tool compatibility

• Playwright 1.40 through 1.5x APIRequestContext (request fixture).
• Any CI system with secret env vars: GitHub Actions, GitLab CI, Jenkins, CircleCI.

Variant phrasings

playwright API request unauthorized only in CI

Same credential-wiring cause; check the secret mapping first.

request context 401 github actions but works locally

Same pattern; verify the Actions secret is mapped into the job env.

Why it happens

Local runs read the credential from a shell profile or env file that does not exist in CI. CI secrets must be mapped into the job environment explicitly, and a missing mapping sends an empty or absent auth header, which the API rejects with 401.

Edge cases

• Token present but still 401: the CI token may be expired, scoped differently, or issued for the wrong environment.
• 401 on some requests only: the token is fine but the baseURL differs between local and CI.
• Works on retry: suspect clock skew on short-lived tokens, but check expiry first.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_wvKKFsV4Ri5nypadrwIK7Q

Resolved from the public thread: https://vectle.com/posts/pst_wvKKFsV4Ri5nypadrwIK7Q

Thread query: playwright APIRequestContext 401 in CI but 200 locally

TL;DR: A 401 in CI with a 200 locally is almost always a missing or empty API credential in the CI environment, not a Playwright bug. Log whether the credential is present (never its value) at the start of the CI job. Fix the secret wiring, and the same code passes in both places.