fix: correct client-secret response field name - #40
Conversation
Verified live against a running server: the response is
{"client_secret": "..."}, not {"secret": ...} as guessed in #38 —
decoding failed for every real call. Confirmed via a redacted debug
probe that revealed the shape (key names, string lengths) without ever
printing the actual secret value.
"secret" is kept as a serde alias and the {"data": ...} envelope
variant is kept too, for robustness against the shape drifting.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe client-secret response parser now supports the confirmed ChangesClient secret parsing
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to Client-secret decoding now accepts the server’s client_secret response field while preserving older response formats, allowing confidential-client and CLI secret flows to complete without breaking compatible payloads. 🚥 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 |
Bug
ferris-ctl client secret cli(and any confidential client) failed witherror: http error: error decoding response body. This is the gap flagged as unverified in #38 — the response shape was guessed, and the guess was wrong.Fix
The real response is
{"client_secret": "..."}, not{"secret": ...}. Confirmed by fetching the endpoint and inspecting a redacted version of the response (key names and string lengths only, secret value never printed anywhere, including in my own output) rather than reading the actual secret.ClientSecretPayloadnow matchesclient_secretas the primary key, withsecretkept as a serde alias and the{"data": ...}envelope variant kept too, in case the shape isn't perfectly consistent across client types/server versions.Verification
Ran
ferris-ctl client secret cliagainst the local server, redirected stdout to a file without reading it, and checked only the exit code (0) and byte count (17 = 16-char secret + newline, matching the length observed in the earlier redacted probe). Confirms the fix without exposing the secret in this conversation.Test plan
cargo build --workspacecargo test --workspace(81 passed, updated shape tests)cargo clippy --workspace --all-targets --all-features -- -D warningsSummary by CodeRabbit
client_secretformat.