fix(secrets): avoid exec target gateway failures#96914
Conversation
|
Thanks for the context here. I swept through the related work, and this is now duplicate or superseded. Close: the same reply-path exec SecretRef log-flood bug is already covered by an open, clean, proof-positive replacement PR, while this PR lacks real behavior proof and changes gateway Canonical path: Close this PR and keep review focused on #96661, which addresses the same bug at the CLI preflight boundary with positive real behavior proof. So I’m closing this here and keeping the remaining discussion on #96661. Review detailsBest possible solution: Close this PR and keep review focused on #96661, which addresses the same bug at the CLI preflight boundary with positive real behavior proof. Do we have a high-confidence way to reproduce the issue? Yes at source level: queued replies request agent-runtime targets that include model-provider credentials, and current main only skips the gateway RPC for gateway credential exec refs. I did not run a live gateway reply turn in this read-only review. Is this the best way to solve the issue? No for this branch: the superseding CLI preflight approach is safer because it avoids the expected failing RPC before crossing the gateway protocol boundary, while this PR changes runtime Security review: Security review cleared: No concrete security or supply-chain defect was found; the credential-routing behavior change is captured as compatibility/auth-provider merge risk. AGENTS.md: found and applied where relevant. What I checked:
Likely related people:
Codex review notes: model internal, reasoning high; reviewed against 448b7c75b669. |
|
ClawSweeper applied the proposed close for this PR.
|
What Problem This Solves
Fixes #96653.
secrets.resolvecould return a genericUNAVAILABLEfor reply-path command secret resolution when a broad target set included model-provider exec SecretRefs that were not materialized in the active runtime snapshot. That made the gateway log a noisy per-turn failure even though the CLI command-secret path can still degrade to local fallback for the unresolved exec target.Why This Change Was Made
The gateway runtime resolver now returns the assignments it can prove from the active snapshot when the remaining unresolved command targets are exec-backed SecretRefs. Non-exec unresolved targets still fail as before, and the CLI-side fallback remains responsible for resolving or degrading the unresolved exec paths.
This keeps the owner boundary in the gateway runtime secret resolver instead of adding a CLI shortcut that would bypass already-materialized gateway snapshot values.
User Impact
Users with exec-backed model-provider credentials should no longer see misleading reply-path
secrets.resolve failed/UNAVAILABLEgateway log noise for otherwise recoverable command-secret resolution. Already-resolved gateway snapshot credentials continue to be returned normally.Evidence
node_modules/.bin/oxfmt --write --threads=1 src/secrets/runtime-command-secrets.ts src/secrets/runtime-command-secrets.test.tsgit diff --checknode scripts/run-vitest.mjs src/secrets/runtime-command-secrets.test.ts src/cli/command-secret-gateway.test.ts -- --reporter=verbosepassed: 2 shards, 37 tests.agents/skills/autoreview/scripts/autoreview --mode local --parallel-tests "node scripts/run-vitest.mjs src/secrets/runtime-command-secrets.test.ts src/cli/command-secret-gateway.test.ts -- --reporter=verbose"passed with no accepted/actionable findings