fix: restore setActiveModel in activateFallbackMode

[ved015]

Summary

Restores the fix from #16269. The fallback mechanism fails to persist across turns when using setModel() instead of setActiveModel().

Pre-Merge Checklist

• Updated relevant documentation and README (if needed)
• Added/updated tests (if needed)
• Noted breaking changes (if any)
• Validated on required platforms/methods:
  • MacOS
    • npm run
    • npx
    • Docker
    • Podman
    • Seatbelt
  • Windows
    • npm run
    • npx
    • Docker
  • Linux
    • npm run
    • npx
    • Docker

[gemini-code-assist]

Summary of Changes

Hello @ved015, 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 resolves a critical bug in the model fallback mechanism where the fallback model would not persist across turns. By switching to the correct setActiveModel method and emitting a model changed event, the system now reliably maintains the fallback model state, improving the robustness of the application's model handling.

Highlights

• Bug Fix: This pull request restores a previous fix (from Fix an issue where the agent stops prematurely #16269) addressing an issue where the model fallback mechanism failed to persist across turns. The root cause was using setModel() instead of setActiveModel().
• Corrected Model Activation: The activateFallbackMode method in config.ts has been updated to correctly use this.setActiveModel(model) to ensure the fallback model is properly registered and persists.
• Event Emission: A coreEvents.emitModelChanged(model) call was added within activateFallbackMode to ensure that listeners are notified when the active model changes due to fallback activation.
• Test Updates: Corresponding tests in flashFallback.test.ts were updated to reflect the change, now asserting against config.getActiveModel() for the fallback model and ensuring config.getModel() remains the default model.

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 correctly fixes an issue where the fallback model was persisting across turns by switching from setModel to setActiveModel, ensuring only the temporary active model is updated. However, a high-severity vulnerability was identified: the activateFallbackMode function does not validate the model parameter, which could allow an attacker to specify an unauthorized model, potentially leading to denial of service or other injection vulnerabilities. Additionally, it's recommended to ensure the model-changed event is emitted only when the active model actually changes to prevent unnecessary work.

Might cause another bug

[ved015]

Hi @galz10, what specific bug are you concerned about? happy to discuss specific concerns

I documented my full findings in a comment on #16390.

[sehoon38]

Hey, thanks for the PR and the thorough explanation! Since we use this model in several other areas (like the footer), not updating it would cause inconsistencies across the app. This PR #17051 will fix the issue, so will close this PR for now.
Also, I appreciate the feedback regarding modelAvailabilityService.reset. We'll revisit that soon, our requirements have changed quite a bit recently, so that logic likely needs an update.

[ved015]

@sehoon38 no issue thank you reviewing