fix: properly handle auth prompt in batch providers#349
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly improves the resilience of batch secret resolution by implementing a mechanism to detect authentication failures, prompt the user for re-authentication via Highlights
Changelog
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request correctly extends the authentication prompt and retry logic to batch secret providers. The implementation introduces a new helper function to detect authentication errors within batch results and adds the retry flow. The logic appears correct. I've suggested a small refactoring to simplify the new control flow and reduce code duplication, improving maintainability.
Greptile SummaryThis PR extends the auth-retry logic in Key changes:
Confidence Score: 4/5
Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[try_batch_with_auth_retry] --> B[try_get_secrets_batch]
B --> C{Result?}
C -->|Err - hard failure| D[prompt_and_run_auth]
D -->|Ok false - declined/unavailable| E[handle_batch_error\nif_missing per-secret]
D -->|Ok true - auth ran| F[retry try_get_secrets_batch]
F -->|Ok batch_results| G[process_batch_results\nif_missing per-entry]
F -->|Err retry_error| H[Propagate error]
C -->|Ok batch_results| I{extract_auth_error\n_from_batch?}
I -->|None - no auth error| J[process_batch_results\nnormal path]
I -->|Some auth_err| K[prompt_and_run_auth\nNEW PATH]
K -->|Ok false - declined/unavailable| L[process_batch_results\noriginal results with if_missing]
K -->|Ok true - auth ran| M[retry try_get_secrets_batch\nNEW PATH]
M -->|Ok retry_results| N[process_batch_results\nretry results]
M -->|Err| O[Propagate error\nno if_missing]
style K fill:#c8f7c5
style M fill:#c8f7c5
style N fill:#c8f7c5
style L fill:#c8f7c5
|
6712bc7 to
9f5aecc
Compare
| let auth_error = extract_auth_error_from_batch(&batch_results); | ||
| if let Some(ref auth_err) = auth_error | ||
| && prompt_and_run_auth(config, provider_config, provider_name, auth_err)? | ||
| { | ||
| // Auth prompt successful, retry the batch operation. | ||
| let retry_results = try_get_secrets_batch( | ||
| config, | ||
| profile, | ||
| provider_name, | ||
| provider_config, | ||
| provider_secrets, | ||
| ) | ||
| .await?; | ||
| process_batch_results(secrets, config, retry_results, results)?; | ||
| return Ok(std::mem::take(results)); | ||
| } | ||
| // No auth error, or user declined auth prompt. Process original results. | ||
| process_batch_results(secrets, config, batch_results, results)?; | ||
| Ok(std::mem::take(results)) |
There was a problem hiding this comment.
Auth-error "decline" path silently drops if_missing for non-auth errors mixed in the same batch
When batch_results contains both a ProviderAuthFailed entry and other error types (e.g. ProviderSecretNotFound), extract_auth_error_from_batch returns the first auth error and the auth prompt is shown. If the user confirms, the retry replaces all results — including entries for secrets that actually had a non-auth error on the first attempt. Those non-auth secrets get a fresh retry they don't really need, and if the retry happens to surface a different error the original if_missing context is gone.
If the user declines (or no auth command exists), process_batch_results is called with the original batch_results and if_missing is respected for each entry individually — so this path is fine.
The risk is specifically on the confirm+retry path: consider secrets A (auth error) and B (secret-not-found, if_missing=warn). After auth succeeds, the retry fetches both. If the retry returns a hard Err for B (perhaps transiently), ? propagates it — bypassing the if_missing=warn that would have swallowed it on the first pass. This is a subtle but real divergence from the pre-PR behavior for mixed-error batches.
This may be acceptable given the PR's stated trade-offs, but it's worth documenting explicitly in a comment.
There was a problem hiding this comment.
I noted that in the PR description.
### 🚀 Features - **(sync)** add --local-file output target by [@florian-lackner365](https://github.com/florian-lackner365) in [#317](#317) ### 🐛 Bug Fixes - properly handle auth prompt in batch providers by [@johnpyp](https://github.com/johnpyp) in [#349](#349) ### 🛡️ Security - **(mcp)** redact secret values from exec output by [@jdx](https://github.com/jdx) in [#357](#357) ### 📦️ Dependency Updates - lock file maintenance by [@renovate[bot]](https://github.com/renovate[bot]) in [#344](#344) - update jdx/mise-action digest to 5228313 by [@renovate[bot]](https://github.com/renovate[bot]) in [#351](#351) - update swatinem/rust-cache digest to e18b497 by [@renovate[bot]](https://github.com/renovate[bot]) in [#352](#352) - update taiki-e/upload-rust-binary-action digest to 381995c by [@renovate[bot]](https://github.com/renovate[bot]) in [#353](#353) - update dependency vue to v3.5.30 by [@renovate[bot]](https://github.com/renovate[bot]) in [#354](#354) - update rust crate openssl-sys to v0.9.112 by [@renovate[bot]](https://github.com/renovate[bot]) in [#355](#355) - update rust crate clap to v4.6.0 by [@renovate[bot]](https://github.com/renovate[bot]) in [#356](#356) ### New Contributors - @florian-lackner365 made their first contribution in [#317](#317) --------- Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
This PR allows batch secret resolution to use
auth_commandfallback behavior (previously just warned and passed through without the secret injected).Considerations:
AWS KMSandAWS PM) may have the same resolution (aws sso login) to fix the providers, but would be run twice as the batches are run concurrently. In other words, there's noauth_commanddedupe built-in (this was pre-existing).is_missing = none / warnwas specified previously on every secret under a given provider, then this command will now fail instead of hitting that if_missing behavior. This could be changed, but semantically it kind of feels to me likeif_missingisn't meant to swallow auth errors? Very open to feedback here.I tested this fix on my own monorepo which uses aws kms, and it works properly afaict.