Skip to content

fix: properly handle auth prompt in batch providers#349

Merged
jdx merged 2 commits intojdx:mainfrom
johnpyp:fix/auth-prompt-for-batch-providers
Mar 10, 2026
Merged

fix: properly handle auth prompt in batch providers#349
jdx merged 2 commits intojdx:mainfrom
johnpyp:fix/auth-prompt-for-batch-providers

Conversation

@johnpyp
Copy link
Copy Markdown
Contributor

@johnpyp johnpyp commented Mar 10, 2026

This PR allows batch secret resolution to use auth_command fallback behavior (previously just warned and passed through without the secret injected).

Considerations:

  • This PR doesn't address the fact that someone using mixed provider batches (e.g AWS KMS and AWS 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 no auth_command dedupe built-in (this was pre-existing).
  • If is_missing = none / warn was 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 like if_missing isn'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.

@gemini-code-assist
Copy link
Copy Markdown
Contributor

Summary of Changes

Hello, 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 auth_command, and then automatically retry the batch operation. This change ensures that batch secret retrieval processes can recover from temporary authentication issues without manual intervention, streamlining workflows that rely on multiple secrets from a single provider.

Highlights

  • Batch Authentication Retry: Enabled the auth_command fallback behavior for batch secret resolution, allowing the system to prompt for authentication and retry the batch operation upon ProviderAuthFailed errors.
  • Error Extraction: Introduced a new helper function, extract_auth_error_from_batch, to efficiently identify and extract the first authentication error from a set of batch results.
  • Improved Error Handling: Modified the try_batch_with_auth_retry function to integrate the new authentication error detection and retry logic, enhancing the robustness of batch secret retrieval.
Changelog
  • src/secret_resolver.rs
    • Modified try_batch_with_auth_retry to include logic for detecting and handling ProviderAuthFailed errors within batch results.
    • Implemented a retry mechanism for batch secret resolution after a successful authentication prompt.
    • Added the extract_auth_error_from_batch function to find and clone authentication errors from batch results.
Using Gemini Code Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

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

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread src/secret_resolver.rs
@greptile-apps
Copy link
Copy Markdown

greptile-apps Bot commented Mar 10, 2026

Greptile Summary

This PR extends the auth-retry logic in try_batch_with_auth_retry to cover the case where a provider returns an outer Ok but embeds ProviderAuthFailed errors inside individual per-secret entries of the result map — the path that was previously silently falling through to process_batch_results without prompting the user. The fix mirrors the existing retry flow already present in the Err(error) arm.

Key changes:

  • New extract_auth_error_from_batch helper scans a HashMap<String, Result<String>> for any ProviderAuthFailed variant and returns an owned clone so it doesn't hold a borrow over batch_results.
  • When an auth error is detected in the Ok arm, prompt_and_run_auth is called; on confirmation the full batch is retried and the retry results replace the original.
  • When no auth command is available, the user declines, or the error is not an auth error, process_batch_results falls through to process the original results with per-secret if_missing logic — preserving prior behaviour.
  • No tests were added for the new code path. The extract_auth_error_from_batch helper and the Ok-arm retry flow have no unit or integration test coverage, making the new behaviour harder to verify and regress-protect.
  • The doc-comment on try_batch_with_auth_retry still describes only the Err path and should be updated.
  • In mixed-error batches (some ProviderAuthFailed, some other errors), the confirm+retry path re-fetches all secrets together, and a hard Err from the retry propagates without if_missing handling — a pre-existing characteristic of the retry path that applies equally here.

Confidence Score: 4/5

  • Safe to merge with minor caveats; the core logic is sound and consistent with the existing Err-arm retry pattern.
  • The new code correctly mirrors the established auth-retry pattern, the happy path and the decline path both behave as expected, and there are no data-loss or security issues. Score is 4 rather than 5 primarily because there are no tests for the new code path, and the mixed-error batch edge case could silently bypass if_missing on a hard retry failure.
  • src/secret_resolver.rs — specifically the new Ok(batch_results) arm and extract_auth_error_from_batch.

Important Files Changed

Filename Overview
src/secret_resolver.rs Adds auth-retry handling to the Ok(batch_results) arm of try_batch_with_auth_retry — the main path where providers return a successful map but embed ProviderAuthFailed errors per-entry. Introduces extract_auth_error_from_batch helper. Minor doc-comment staleness and a subtle edge-case around mixed-error batches on the confirm+retry path.

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
Loading

Comments Outside Diff (1)

  1. src/secret_resolver.rs, line 691-693 (link)

    Stale doc-comment no longer accurate

    The doc-comment still says "If the initial attempt fails…" but now the function also handles the case where the initial attempt succeeds (Ok) yet carries per-entry ProviderAuthFailed errors inside batch_results. The comment should be updated to cover both branches.

Last reviewed commit: 9e6a976

Comment thread src/secret_resolver.rs Outdated
@johnpyp johnpyp force-pushed the fix/auth-prompt-for-batch-providers branch from 6712bc7 to 9f5aecc Compare March 10, 2026 19:49
Comment thread src/secret_resolver.rs
Comment on lines +714 to 732
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))
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noted that in the PR description.

@jdx jdx merged commit 373e16d into jdx:main Mar 10, 2026
14 of 15 checks passed
jdx pushed a commit that referenced this pull request Mar 13, 2026
### 🚀 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants