[fix] Read provider-key presence from value_status, not the write-only value - #6691
Conversation
…write-only value The playground's Model section decided whether the project holds a key for the selected model's provider by reading the key value off the vault row. Secrets are write-only on staging and on every dev stack, so `/secrets/` returns no value and reports presence through `value_status.configured`, which the transform surfaces as `hasKey`. Every connected project therefore read as keyless, and the amber "Connect key" badge and its "Connect the model's provider key to run this agent." tooltip stayed up across reloads while the agent ran on that same key. The rule moves into `shouldPromptForProviderKey` and asks `hasStoredKey`, the one vault presence rule. Its exemptions are unchanged: a self-managed connection signs itself in, a named connection points at a vault record this rule never looks up, and an unresolved vault prompts for nothing.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
@coderabbitai review |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository YAML (base), Organization UI (inherited) Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (4)
Included review availability: Your plan provides up to 8 included reviews per hour; 0 remain after this review. 📝 SummarySummary by CodeRabbit
WalkthroughThe change adds a shared provider-key prompt helper, replaces inline model-harness conditions, clarifies state usage, updates related documentation, and adds unit coverage for connection and vault-key states. ChangesProvider key prompting
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to Provider-key badges and credential warnings now correctly recognize configured write-only keys while preserving existing connection and loading behavior. The covered change is ready to merge. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
|
Reviews on this diff. Codex, extra-high effort, on this branch off the current release head: "Ship it as the Model-badge fix. No actionable findings." It checked the four things worth checking after the split. The commit sits directly on CodeRabbit: no actionable comments. An earlier Codex pass reviewed the same rule inside the larger branch and asked for three changes, all of which are in this commit: the name For anyone reading the history: four further commits exist on |
Railway Preview Environment
Updated at 2026-09-08T20:38:48.905Z |
1 participant
Context
The playground's Model section kept asking for a provider key after one was added, while the agent ran on that same key. Reproduced on staging v0.115.3 with the steps from #6660: fresh project, Settings, AI providers, Add provider, OpenAI, paste a working key, Test reports
133 models fetched, Done. The provider row lists the key. Back in the playground the Model row still shows the amberConnect keybadge and its "Connect the model's provider key to run this agent." tooltip, and it survives a reload. The turn that follows reaches OpenAI and comes back with a billing error, so the key is plainly in use.The cause is a presence check reading the wrong field. Secrets are write-only on staging and on every dev stack, so
/secrets/returns no value at all:Presence rides on
value_status.configured, which the transform surfaces ashasKey, andhasStoredKeyis the one rule that reads it. The Model section tested!providerVaultEntry.keyinstead, which is true for every write-only row, so a connected project read as keyless forever.Changes
The rule moves into
shouldPromptForProviderKey(providerKeyPrompt.ts), which drives the badge, the section tooltip and the section auto-opening. Its exemptions are unchanged. Aself_managedconnection signs itself in through the harness, and a namedagentaconnection points at one vault record that this rule never looks up, so a missing standard key for the family says nothing about it.vaultLoadedstill gates everything, so nothing prompts while the vault query is pending.providerNeedsKeyalso drives the Provider credentials section's warning status, so that surface stops warning too.One comment in the vault persister claimed
!!secret.keywas the presence rule. It is not, and it now points athasStoredKey.Tests
packages/agenta-entity-ui/tests/unit/providerKeyPrompt.test.tscovers the row shapes the vault really serves: unconnected, write-only connected, readable connected, both of those restored from IndexedDB, and a record that says the key is gone while a stale value lingers. It fails against the old rule and passes against the new one.pnpm --filter @agenta/entity-ui test: 710 passed.pnpm --filter @agenta/entities exec vitest run tests/unit: 1600 passed.pnpm lint-fixandpnpm run format: clean.Browser verification
Before, on staging with a real OpenAI key, and after, on a PR preview with the same vault row shape, counting visible instances rather than matching text:
Screenshots are on the dev box under
~/agenta-qa-evidence/2026-09-08-issue-6660/, before and after plus the no-key regression.Note on #6660
That issue described a second symptom, a stale banner above the composer, and it was closed as invalid: the banner text sits in the DOM in collapsed instances, so a whole-document text search reported it on every page whether or not anything was drawn. The closing comment keeps this half: "The
Connect keybadge bug that #6677 fixes in its first commit is real and was found independently on a fresh staging project. That fix stands on its own evidence." This PR is that fix, alone, off the current release head.What to QA
Connect keybadge, and no "Connect the model's provider key" tooltip on the section header.