[Daily #1330] openai-compatible — the persisted node's credential reads back empty; the assertion may be the last inline copy of the premise #14311 removed (recurrent 2×)

[Victor-w-Madeira]

Spun out of daily-failure triage #1330 (run 31093877484, 2026-08-06).

Upstream: not filed — see langflow-ai/langflow#14311 (an intentional upstream change, not a defect report)

Symptom

The @stable test that points a Basic Prompting flow at a model discovered through the OpenAI-Compatible provider hard-failed on both attempts that ran, inside the step point a Basic Prompting flow at the discovered model. The persisted node's binding polls out after 30 s reading credential: "" where the assertion expects "OPENAI_COMPATIBLE_API_KEY". The models half of the same assertion is correct (["gpt-4o-mini"]) — only the credential differs. @stable was auto-removed by the workflow (commit cb3082d).

Spec (line)	Waits for	Signature
tests/tests-automations/regression/core-functionality/model-provider/openai-compatible-provider-setup.spec.ts:620 ("a discovered model runs a flow through the OpenAI Compatible provider")	expect.poll(persistedModelBinding) → { models: [TEST_MODEL], credential: KEY_VAR } (30 s)	Error: expect(received).toEqual(expected) // deep equality

Why these failures are one cause

Single spec. Kept separate from this run's other OpenAI hard failure (openai-provider.spec.ts:201) despite the dataset's provider_wide_cluster hint: that one is a run that produces no output, this one is a field on a persisted node — the flow here never had to reach the provider at all for the assertion to fail. Also not grouped with the same file's flake at line 558 (the live model catalog came back empty on attempt 0 and correct on both retries), which is a different observation with its own likely cause.

Preliminary read (descriptive — NOT a verdict)

Named lead, with dates that line up — this assertion may be asserting a binding upstream removed on purpose. Descriptive, not a verdict:

• Upstream 646bdd6b (langflow-ai/langflow#14311, "fix(models): stop automatic provider field binding") deleted the block that pre-populated a provider field's value with the credential variable name. The PR states the new contract: the build-config refresh "never changes value or load_from_db. Empty fields use the existing provider-specific DB/environment fallback at runtime." Under that contract an empty credential on the persisted node is correct.
• That change was forward-ported into release-1.12.0 — the branch the nightly image is built from — on 2026-08-04 (b65e195eb1), verified by ancestry in The #751 credential-settle guard asserts a binding upstream removed on purpose (#14311) — 19 @stable specs fail by design on 1.11.2 #1274.
• This spec's first two failures are the 2026-08-05 and 2026-08-06 dailies — the first two dailies after the forward-port. It has no earlier occurrence in the 30-day window.
• The suite already met this premise once: The #751 credential-settle guard asserts a binding upstream removed on purpose (#14311) — 19 @stable specs fail by design on 1.11.2 #1274 ("The [Daily #744] agent/flow execution does not complete — div-chat-message / 'built successfully' never render (3 specs) #751 credential-settle guard asserts a binding upstream removed on purpose (#14311)", closed 2026-08-05) migrated the shared helper tests/helpers/flows/agent-credential-settle.ts off the stored-credential axis. This spec asserts the same shape inline in its own body — its comment even says "same shape agent-credential-settle.ts reads for the Agent node" — so it did not receive that migration. Grep confirms tests/tests-automations/regression/core-functionality/model-provider/openai-compatible-provider-setup.spec.ts:691 is the only remaining inline credential: assertion of this kind in the suite.

What this lead does not settle. #14311 removed the automatic binding on a build-config refresh; this spec reaches the state through an explicit provider configuration plus a model selection, which is not obviously the same path. Whether an empty credential is the intended outcome here is exactly what has to be measured, not assumed.

Investigation directive

All paths must be investigated independently, and the product is the prime suspect first — the #14311 lead above is attractive precisely because it would let the analysis close early, so it must be tested rather than adopted. Concretely: on the current nightly, drive this spec's path by hand and read GET /api/v1/flows/{id} directly; establish whether the empty credential is the contract #14311 describes, or a real persistence failure on this provider (the models half persisting correctly while credential does not is a fact that fits both readings and must be explained by whichever one is adopted). Then confirm the outcome the assertion actually exists to protect: that the run resolves this provider's key and not another's. Only after the regression hypothesis is ruled out, move to the test path (adopt #1274's approach — validate the outcome, not the storage detail), then the environment.

Deliverables (Done when)

• Root cause confirmed per spec (product regression vs. test/wait-strategy vs. environment), with evidence on the current nightly.
• Each spec passes reliably (multiple clean --retries=0 runs), fixing waits/flow as needed.
• Quarantine lifted in the fix PR — remove test.fixme and restore @stable, re-validated per CONTRIBUTING.md. (Nothing to lift if nothing was quarantined.)
• If the root cause is a product (Langflow) regression: recorded as such here, and this issue stays open until the upstream fix lands in langflowai/langflow-nightly:latest (or the release-1.x.x branch), is re-validated there, and @stable is restored — not on a test-side mute.
• State explicitly whether the empty credential is #14311's intended contract on this path, with a direct GET /api/v1/flows/{id} reading on the current nightly as evidence.
• If the premise is confirmed stale: migrate this assertion the way The #751 credential-settle guard asserts a binding upstream removed on purpose (#14311) — 19 @stable specs fail by design on 1.11.2 #1274 migrated agent-credential-settle.ts — assert the run resolves the right provider, not that the node stores a credential name — and confirm no other inline copy of the premise remains in the suite.

[rafaelgiln]

Follow-ups filed from this issue's investigation (PR #1369):

• collect-models: the credential write is still missed after #1357, and it costs the PR lane its whole E2E run (recurrence of #1355) #1370 — collect-models still misses the credential write after fix(collect-models): wait for the credential write, not for a clock (#1355) #1357; it cost this PR's E2E lane its whole run, twice, and is hitting other branches too (recurrence of collect-models clicks a Save button still aria-busy from the previous provider — the PR lane aborts and the daily degrades to silent LLM skips #1355).
• mcp-client-agent: a third copy of the credential premise #14311 removed, latent because the spec carries no @stable #1371 — a third copy of the credential premise #14311 removed, in mcp-client-agent.spec.ts:86, spelled api_key?.value — which is why this issue's grep reported the OpenAI-Compatible one as the last. Latent, because that spec carries no @stable.
• A run can execute a model the persisted flow does not name — POST /api/v2/workflows does not build what the database holds #1372 — a run can execute a model the persisted flow does not name: POST /api/v2/workflows did not build what the database holds, measured 2 in 12 with the DB and the widget both correct at send time. PR fix(model-provider): assert the provider, not a credential name upstream stopped writing (#1334) #1369 attributes this state but does not diagnose it.

Also relevant: #1364 (open) covers the num_models 248 → 124 reading on the same spec. Measured evidence posted there — the doubling is intact on 1.12.0.dev19 and the catalog is observable mid-registration, which also explains its 2026-08-06 neighbour. PR #1369 changed that assertion's wait strategy without softening it; the verdict on #1364 is left to whoever picks it up.