fix: surface upstream error details in Gemini CLI OAuth onboarding UI#1910
Conversation
SetOAuthSessionError previously sent generic messages to the management panel (e.g. "Failed to complete Gemini CLI onboarding"), hiding the actual error returned by Google APIs. The specific error was only written to the server log via log.Errorf, which is often inaccessible in headless/Docker deployments. Include the upstream error in all 8 OAuth error paths so the management panel shows actionable messages like "no Google Cloud projects available for this account" instead of a generic failure.
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 enhances the user experience during the Gemini CLI OAuth onboarding process by providing more descriptive and actionable error messages. Instead of generic failure notifications, users will now see the underlying reasons for onboarding issues directly in the management panel, making it easier to understand and resolve problems related to Google Cloud projects or API statuses. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Changelog
Activity
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
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request improves the error reporting for the Gemini CLI OAuth onboarding process by surfacing upstream error details in the UI. The changes are straightforward and correctly replace generic error messages with more specific ones using fmt.Sprintf. This will significantly help users diagnose and resolve onboarding issues.
I have one suggestion to further improve maintainability by consolidating the repeated error handling logic into a helper function, which will reduce duplication and make future updates easier.
| if errAll != nil { | ||
| log.Errorf("Failed to complete Gemini CLI onboarding: %v", errAll) | ||
| SetOAuthSessionError(state, "Failed to complete Gemini CLI onboarding") | ||
| SetOAuthSessionError(state, fmt.Sprintf("Failed to complete Gemini CLI onboarding: %v", errAll)) |
There was a problem hiding this comment.
This change is a great improvement for error reporting. I've noticed that the pattern of calling log.Errorf followed by SetOAuthSessionError with a similar message is repeated for multiple error conditions in this function (e.g., lines 1314, 1323, 1334, 1346, 1359).
To make the code more concise and improve maintainability, you could extract this logic into a helper function.
For example:
// logAndSetError logs an error and sets it on the OAuth session.
func logAndSetError(state, msg string, err error) {
log.Errorf("%s: %v", msg, err)
SetOAuthSessionError(state, fmt.Sprintf("%s: %v", msg, err))
}
// ... then, the call site becomes:
if errAll != nil {
logAndSetError(state, "Failed to complete Gemini CLI onboarding", errAll)
return
}This would consolidate the duplicated logic and strings, making the error handling blocks cleaner.
2 participants
Summary
SetOAuthSessionErrorinRequestGeminiCLITokenpreviously sent generic messages to the management panel (e.g. "Failed to complete Gemini CLI onboarding"), hiding the actual error returned by Google APIslog.Errorf, which is often inaccessible in headless/Docker deploymentsfmt.Sprintf, so the management panel shows actionable messages like "no Google Cloud projects available for this account" instead of a generic failureChanges
File:
internal/api/handlers/management/auth_files.goonboardAllGeminiProjectsfail"Failed to complete Gemini CLI onboarding"fmt.Sprintf("...onboarding: %v", errAll)ensureGeminiProjectsEnabledfail"Failed to verify Cloud AI API status"fmt.Sprintf("...status: %v", errVerify)"Google One auto-discovery failed"fmt.Sprintf("...failed: %v", errSetup)"Failed to verify Cloud AI API status"fmt.Sprintf("...status: %v", errCheck)"Cloud AI API not enabled"fmt.Sprintf("...not enabled for project %s", ts.ProjectID)ensureGeminiProjectAndOnboardfail"Failed to complete Gemini CLI onboarding"fmt.Sprintf("...onboarding: %v", errEnsure)"Failed to verify Cloud AI API status"fmt.Sprintf("...status: %v", errCheck)"Cloud AI API not enabled"fmt.Sprintf("...not enabled for project %s", ts.ProjectID)Test plan
go build ./...passes