Skip to content

[core] Enable EventEngine for Python by default, and EventEngine fork support in Python and Ruby#41432

Closed
murgatroid99 wants to merge 5 commits intogrpc:masterfrom
murgatroid99:python_enable_event_engine2
Closed

[core] Enable EventEngine for Python by default, and EventEngine fork support in Python and Ruby#41432
murgatroid99 wants to merge 5 commits intogrpc:masterfrom
murgatroid99:python_enable_event_engine2

Conversation

@murgatroid99
Copy link
Copy Markdown
Member

I think the only way we can realistically make progress with this migration is by having people start using it.

#37710 (comment) shows that external users' tests can pass with this experiment enabled.

@gemini-code-assist
Copy link
Copy Markdown
Contributor

Summary of Changes

Hello @murgatroid99, 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 enables the EventEngine poller for Python by default, a crucial step in accelerating the migration to the new EventEngine architecture. By making this experiment opt-out rather than opt-in, the goal is to encourage broader adoption and uncover potential issues more rapidly, building on the success of previous external user tests.

Highlights

  • Default Experiment Enablement: The event_engine_poller_for_python experiment is now enabled by default across all relevant configurations, including the experiment metadata, header definitions, and rollout YAML.
  • Accelerating EventEngine Migration: This change aims to accelerate the migration to EventEngine for Python by encouraging wider adoption and testing, building on successful external user tests.

🧠 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 Generative AI Prohibited Use Policy, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

@murgatroid99 murgatroid99 added area/core release notes: yes Indicates if PR needs to be in release notes labels Jan 16, 2026
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 enables the event_engine_poller_for_python experiment by default. This is achieved by updating src/core/lib/experiments/rollouts.yaml, which consequently updates the auto-generated files src/core/lib/experiments/experiments.cc and src/core/lib/experiments/experiments.h. This change will cause gRPC for Python to use the EventEngine-based poller. The changes are correct and consistent with the goal of enabling the experiment for wider testing. I've reviewed the configuration changes and they appear to be correctly implemented without any issues.

Copy link
Copy Markdown
Member

@sergiitk sergiitk left a comment

Choose a reason for hiding this comment

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

Before we enable this by default, we need to add the CI coverage on macOS and make sure it's passing.

@murgatroid99
Copy link
Copy Markdown
Member Author

I modified this to also roll out the event_engine_fork experiment. These two experiments fundamentally go together, because only Python uses fork support, and with EventEngine enabled, Python's fork support will just stop working unless the event_engine_fork experiment is also enabled. All code guarded by the event_engine_fork experiment is also guarded by the GRPC_ENABLE_FORK_SUPPORT compilation flag, which only Python sets (as far as I can tell), so rolling this experiment out won't affect any other language.

@sergiitk
Copy link
Copy Markdown
Member

@asheshvidyut strange. After re-running Bazel Python MacOS Tests on the new pool, I see a whole bunch of test failures like so:

ImportError: dlopen(/Volumes/BuildData/tmpfs/altsrc/github/grpc/.bazel_rbe/sandbox/darwin-sandbox/5092/execroot/_main/bazel-out/darwin_x86_64-fastbuild/bin/src/python/grpcio_tests/tests/observability/_open_telemetry_observability_test.runfiles/_main/src/python/grpcio/grpc/_cython/cygrpc.so, 0x0002): symbol not found in flat namespace (_PyCode_NewWithPosOnlyArgs)

@sergiitk
Copy link
Copy Markdown
Member

The tests passed, but comparing PR logs with master, I see a bunch of new errors (but the test passes)

I0218 19:03:09.341 45797/8451379008 methods.py:514] Running TestCase.ASYNC_UNARY_SAME_CHANNEL
E0218 19:03:09.386956  240395 ev_poll_posix.cc:593] Polling FD from a wrong generation: fd(7, generation: 1)
E0218 19:03:09.387055  240395 ev_poll_posix.cc:593] Polling FD from a wrong generation: fd(7, generation: 1)
E0218 19:03:09.387070  240395 ev_poll_posix.cc:593] Polling FD from a wrong generation: fd(7, generation: 1)
...

This PR @ 8304325:

The last master run @ d4a334a:

Copy link
Copy Markdown
Member

@sergiitk sergiitk left a comment

Choose a reason for hiding this comment

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

LGTM, but we should look into Polling FD from a wrong generation error logs captured in #41432 (comment).

default: true
- name: event_engine_fork
default: false
default: true
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Please correct me if I'm wrong: this doesn't enable fork just for python, AFAIK this applies to all other wrapped language too (including ruby)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

If I'm correct, we should capture this in the PR title.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

As I said in #41432 (comment)

All code guarded by the event_engine_fork experiment is also guarded by the GRPC_ENABLE_FORK_SUPPORT compilation flag, which only Python sets (as far as I can tell), so rolling this experiment out won't affect any other language.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I have realized that I made a mistake in my previous searches, and Ruby does in fact also set the GRPC_ENABLE_FORK_SUPPORT compilation flag, here. I have updated the PR title to include that information.

@murgatroid99 murgatroid99 changed the title [core] Enable EventEngine for Python by default [core] Enable EventEngine for Python by default, and EventEngine fork support in Python and Ruby Feb 24, 2026
@murgatroid99
Copy link
Copy Markdown
Member Author

Based on manual testing with the provided reproduction code, enabling this experiment for Ruby appears to fix #41264.

Zgoda91 pushed a commit to Zgoda91/grpc that referenced this pull request Mar 22, 2026
… support in Python and Ruby (grpc#41432)

I think the only way we can realistically make progress with this migration is by having people start using it.

grpc#37710 (comment) shows that external users' tests can pass with this experiment enabled.

<!--

If you know who should review your pull request, please assign it to that
person, otherwise the pull request would get assigned randomly.

If your pull request is for a specific language, please add the appropriate
lang label.

-->

Closes grpc#41432

COPYBARA_INTEGRATE_REVIEW=grpc#41432 from murgatroid99:python_enable_event_engine2 af0f0a5
PiperOrigin-RevId: 874842538
asheshvidyut pushed a commit to asheshvidyut/grpc that referenced this pull request Mar 26, 2026
… support in Python and Ruby (grpc#41432)

I think the only way we can realistically make progress with this migration is by having people start using it.

grpc#37710 (comment) shows that external users' tests can pass with this experiment enabled.

<!--

If you know who should review your pull request, please assign it to that
person, otherwise the pull request would get assigned randomly.

If your pull request is for a specific language, please add the appropriate
lang label.

-->

Closes grpc#41432

COPYBARA_INTEGRATE_REVIEW=grpc#41432 from murgatroid99:python_enable_event_engine2 af0f0a5
PiperOrigin-RevId: 874842538
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/core bloat/none lang/core release notes: yes Indicates if PR needs to be in release notes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants