fix: persist events after plugin on_event_callback modifications

[Ponts]

Link to Issue or Description of Change

1. Link to an existing issue (if applicable):

• Closes: 3990

Problem:
on_event_callback executes after append_event, preventing plugin modifications from being persisted #3990

Solution:
Run callbacks before persisting events.

Testing Plan

Ran python tests/unittests and verified all tests passed.
There exists tests that verify that events are yielded from the runner.

Unit Tests:

• I have added or updated unit tests for my change.
• All unit tests pass locally.

Manual End-to-End (E2E) Tests:

Checklist

• I have read the CONTRIBUTING.md document.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have added tests that prove my fix is effective or that my feature works.
• New and existing unit tests pass locally with my changes.
• I have manually tested my changes end-to-end.
• Any dependent changes have been merged and published in downstream modules.

[gemini-code-assist]

Summary of Changes

Hello @Ponts, 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 addresses an issue where modifications made to events by plugins via on_event_callback were not being persisted. The changes reorder the event processing flow to ensure that plugin-modified events are correctly stored in the session, thereby resolving data inconsistency issues.

Highlights

• Event Persistence Logic: The logic for running on_event_callback and applying custom metadata has been reordered to occur before the event is appended to the session. This ensures that any modifications made by plugins to an event are persisted correctly.
• Event Yielding Simplification: The yield statement now consistently yields the event variable after it has potentially been modified by on_event_callback, simplifying the control flow.

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

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

[adk-bot]

Response from ADK Triaging Agent

Hello @Ponts, thank you for creating this PR!

Could you please update the issue number in the PR description? It currently says Closes: #_issue_number_.

In addition, could you please provide more details in the "Testing Plan" section, such as the commands you ran and the output you observed? This information will help reviewers to review your PR more efficiently. Thanks!

[gemini-code-assist]

Code Review

This pull request correctly addresses the issue of persisting events after on_event_callback modifications by reordering the event processing logic. The on_event_callback is now executed, and any modifications are applied to the event, before the event is appended to the session service. The logging for modified events is a good addition for debugging. The simplification of the yield statement is also a positive change.

[gemini-code-assist]

The _apply_run_config_custom_metadata function is called here, after the on_event_callback has potentially modified the event. However, this function is also called earlier in the _exec_with_plugin method (around line 781, outside this diff). Applying custom metadata twice, even if it's a merge operation, is redundant and could lead to confusion or subtle bugs if the run_config.custom_metadata were to change dynamically or if plugins were expected to override certain metadata. Consider ensuring _apply_run_config_custom_metadata is called only once, at the final stage before persistence and yielding, to ensure consistency and avoid unnecessary processing.

[Ponts]

This is done again on the modified events to ensure the custom metadata from the run config is applied.
I am unsure if the live-call code makes use of the metadata for something, and that is why it is applied at the beginning.
I wanted to make a minimal change to ensure modified events are persisted

[GWeale]

Thanks for this fix! The approach is correct for non-live calls, and I confirmed locally that it resolves the persistence issue.

However, I noticed that the fix moves on_event_callback inside the else block, which means it no longer runs for live/bidi calls (is_live_call=True). In the original code, the callback was outside both branches and ran for all events.

Could you update the PR to ensure on_event_callback also runs (before append_event) for live calls? The live branch has multiple append_event calls that would need similar treatment.

[Ponts]

I have updated the code to run the callbacks in the live/bidi calls block too and fixed the mistake with that it only ran on not-live calls.
I added running callbacks to the buffered events, which was not being done previously.