fix: persist copilot token metadata

[GrothKeiran]

Summary

• Optimization: enable GitHub Copilot to dynamically fetch supported models immediately after credentials are obtained.

Implementation

• Serialize CopilotTokenStorage into Metadata to persist access_token, token_type, and scope alongside user identity fields.
• Keep metadata as the single source of truth to avoid duplicated fields and drift as storage evolves.
• With complete metadata available right after credential capture, the model registry can load dynamic models immediately.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! 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 enhances the GitHub Copilot authentication process by ensuring that critical token metadata, including the access token, token type, and scope, is persistently stored. This improvement allows the model registry to load dynamic models immediately upon authentication, significantly streamlining operations by removing the previous requirement for a service restart.

Highlights

• GitHub Copilot Authentication: Persisted access_token, token_type, and scope fields within the GitHub Copilot authentication metadata during the token saving process.
• Dynamic Model Loading: Enabled immediate loading of dynamic models by the model registry without requiring a service restart, due to the availability of complete authentication metadata.

🧠 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

• internal/api/handlers/management/auth_files.go
  • Added access_token, token_type, and scope to the Copilot token metadata map.

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. ↩

[gemini-code-assist]

Code Review

This pull request updates the GitHub Copilot authentication flow to include the access_token, token_type, and scope in the auth record's metadata. This allows other parts of the system, like the model registry, to access this information immediately without needing a server restart.

The change is correct and addresses the issue described. However, it introduces data duplication between the Storage object and the Metadata map within the Auth record. I've added a comment with a suggestion to refactor this by deriving the metadata from the storage object directly, which would improve long-term maintainability.

[gemini-code-assist]

While this correctly adds the necessary fields to the metadata, it duplicates data already present in the tokenStorage object. This could become a maintenance issue if the CopilotTokenStorage struct is updated in the future, as those changes would need to be manually mirrored here.

To make this more robust and avoid data duplication, you could generate the metadata map directly from the tokenStorage object. This would ensure the metadata is always a complete and accurate reflection of the storage object.

For example, you could use JSON marshaling and unmarshaling to achieve this:

// A helper to convert storage to metadata
func tokenStorageToMetadata(storage any) (map[string]any, error) {
    data, err := json.Marshal(storage)
    if err != nil {
        return nil, err
    }
    var metadata map[string]any
    if err := json.Unmarshal(data, &metadata); err != nil {
        return nil, err
    }
    return metadata, nil
}

// In RequestGitHubToken:
tokenStorage := copilotAuth.CreateTokenStorage(bundle)
metadata, err := tokenStorageToMetadata(tokenStorage)
if err != nil {
    c.JSON(http.StatusInternalServerError, gin.H{"error": fmt.Sprintf("failed to create token metadata: %v", err)})
    return
}

record := &cliproxyauth.Auth{
    Provider: "github-copilot",
    FileName: fileName,
    Storage:  tokenStorage,
    Metadata: metadata,
}

This approach centralizes the definition of the persisted data in the CopilotTokenStorage struct, improving maintainability.