Fix gRPC failures in Python PreCommit tests

[aIbrahiim]

Fixes: #34739
Successful run: https://github.com/aIbrahiim/beam/actions/runs/21150810363

---

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

• Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
• Update CHANGES.md with noteworthy changes.
• If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI or the workflows README to see a list of phrases to trigger workflows.

[gemini-code-assist]

Summary of Changes

Hello @aIbrahiim, 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 gRPC failures in Python PreCommit tests by standardizing the pipeline runner used within various test cases. By explicitly setting the DirectRunner for beam.Pipeline objects in these tests, it ensures a predictable execution environment, thereby mitigating issues that might arise from implicit runner selection. Additionally, a small initialization fix is included in a YAML testing utility.

Highlights

• Explicit DirectRunner Usage in Tests: Several Python test files have been updated to explicitly specify 'DirectRunner' when initializing beam.Pipeline instances. This change aims to prevent gRPC failures by ensuring a consistent and controlled execution environment for these tests.
• YAML Testing Utility Initialization: A minor change was introduced in sdks/python/apache_beam/yaml/yaml_testing.py to explicitly initialize self._fixes to None in the __init__ method of a test class.

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

[aIbrahiim]

@damccorm could you please review this?

[github-actions]

Checks are failing. Will not request review until checks are succeeding. If you'd like to override that behavior, comment assign set of reviewers

[github-actions]

Assigning reviewers:

R: @tvalentyn for label python.

Note: If you would like to opt out of this review, comment assign to next reviewer.

Available commands:

• stop reviewer notifications - opt out of the automated review tooling
• remind me after tests pass - tag the comment author after tests pass
• waiting on author - shift the attention set back to the author (any comment or push by the author will return the attention set to the reviewers)

The PR bot will only process comments in the main thread (not review comments).

[tvalentyn]

What is the value for runner if we don't set runner explicitly in these tests?

[aIbrahiim]

the default runner is supposed to be DirectRunner but the tests were mysteriously using a grpc based runner (FnApiRunner/PortableRunner) in the CI environment, which caused the DEADLINE_EXCEEDED errors

[tvalentyn]

Generally, a DirectRunner is a runner that executes the pipeline locally. We have multiple implementations of DirectRunner, see https://github.com/apache/beam/blob/600bd612dc2ef495fef08675398361159f7a03df/sdks/python/apache_beam/runners/direct/direct_runner.py.

The DirectRunner should already be a default (when a runner is not explicitly specified). However, which implementation is used, should be defined by the logic in direct_runner.py.

Originally, it should be set to 'SwitchingDirectRunner' , meaning that an underlying implementation will be defined based on which DirectRunner implementation supports the pipeline.

beam/sdks/python/apache_beam/runners/direct/direct_runner.py

Line 626 in 600bd61

DirectRunner = SwitchingDirectRunner

The BundleBasedDirect Runner is the oldest implementation and is expected to be used the least. I think these days we should be using either the FnAPI runner or the PrismRunner.

grpc errors is a problem that we have in the FnAPI runner, and possibly also in the PrismRunner - I am not sure. But ultimately, both FnAPI runner and PrismRunner use grpc and we need to find a way how to use these runners in our test suites without grpc flakes.

[tvalentyn]

I would try to look at the following:

1. which runner is selected when we don't specify 'runner' parameter explicitly, and why (b/c it is not a good state to have unsolved mysteries). I didn't expect the setting runner=DirectRunner to have an effect.

2. does prism runner support these tests? if so, why it is not being used.

3. we might still have to solve the core problem of tuning grpc for our test suites, i don't think switching to bundlebased direct runner is a viable option long term.

[aIbrahiim]

Ahh ok, I now understand that DirectRunner = SwitchingDirectRunner which automatically selects PrismRunner which FnApiRunner which BundleBasedDirectRunner based on pipeline compatibility so since both PrismRunner and FnApiRunner use grpc the timeout errors are expected behavior with the current configuration

[damccorm]

Yeah, I agree with Valentyn. There are some tests which pin to the FnApiRunner (e.g.

beam/sdks/python/apache_beam/yaml/yaml_specifiable_test.py

Line 62 in 600bd61

with beam.Pipeline('FnApiRunner', options=pipeline_options) as p:

) but those are for pretty specific reasons. In general, we should be using the default direct runner for almost all of our local tests

[tvalentyn]

drive-by comment: to request a review from a specific person, use R: <@ username>, otherwise bot will auto-assign - using a bot is also ok if a specific reviewer is not required.