Fix Dataflow legacy worker abort loop thread death issue - #38894
Conversation
Summary of ChangesHello, 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 addresses a critical issue where logical abort signals were incorrectly interpreted as thread interrupts, causing worker threads to fail prematurely and hang the harness. By adjusting the exception hierarchy and improving the failure handling in the worker harness, the system now correctly manages abort signals and ensures proper process termination upon worker thread death. Highlights
New Features🧠 You can now enable Memory (public preview) 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 AssistThe 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
Customization To customize the 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 Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. 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. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces changes to worker termination and exception handling. Specifically, it throws a RuntimeException when processWork completes in DataflowBatchWorkerHarness and changes ReadLoopAbortedException to extend InterruptedIOException instead of InterruptedException. Feedback highlights that throwing an unconditional exception upon worker exit could disrupt graceful shutdowns, and changing the exception hierarchy may cause issues with existing catch blocks that expect InterruptedException.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
Previously, when the service asked the worker to abort, it threw ReadLoopAbortedException, which extends InterruptedException. MapTaskExecutor caught this and, in an attempt to preserve the interrupted status, set the interrupted bit on the thread. However, since this was a logical abort and not a real thread interrupt, setting the interrupted bit caused subsequent operations on the thread (like the backoff sleep in DataflowBatchWorkerHarness) to immediately fail with InterruptedException, leading to all worker threads dying and the harness hanging. This fix changes the interruption handling in MapTaskExecutor to not set the interrupted bit if it is just rethrowing the InterruptedException. Since we are throwing the exception, we can rely on the caller to set the bit if they swallow it and need to preserve it. Ref: b/512366613
cf3538f to
91af38b
Compare
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request removes the block that re-interrupts the current thread when an InterruptedException is caught inside MapTaskExecutor.java. There are no review comments, and I have no feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
|
R: @scwhittle |
There was a problem hiding this comment.
Code Review
This pull request removes the logic that re-interrupts the current thread when an InterruptedException is caught in MapTaskExecutor.java. There are no review comments to evaluate, so I have no feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
|
Stopping reviewer notifications for this pull request: review requested by someone other than the bot, ceding control. If you'd like to restart, comment |
scwhittle
left a comment
scwhittle
left a comment
There was a problem hiding this comment.
I think we might want to make some of the other suggestions to harden against the threads exiting and leaving the worker idle but those can be separate follow ups as this is the root-cause.
Previously, when the service asked the worker to abort, it threw ReadLoopAbortedException, which extends InterruptedException. MapTaskExecutor caught this and, in an attempt to preserve the interrupted status, set the interrupted bit on the thread. However, since this was a logical abort and not a real thread interrupt, setting the interrupted bit caused subsequent operations on the thread (like the backoff sleep in DataflowBatchWorkerHarness) to immediately fail with InterruptedException, leading to all worker threads dying and the harness hanging. This fix changes the interruption handling in MapTaskExecutor to not set the interrupted bit if it is just rethrowing the InterruptedException. Since we are throwing the exception, we can rely on the caller to set the bit if they swallow it and need to preserve it. Ref: b/512366613
2 participants
Previously, when the service asked the worker to abort, it threw ReadLoopAbortedException, which extends InterruptedException. MapTaskExecutor caught this and, in an attempt to preserve the interrupted status, set the interrupted bit on the thread. However, since this was a logical abort and not a real thread interrupt, setting the interrupted bit caused subsequent operations on the thread (like the backoff sleep in DataflowBatchWorkerHarness) to immediately fail with InterruptedException, leading to all worker threads dying and the harness hanging.
This fix changes the interruption handling in MapTaskExecutor to not set the interrupted bit if it is just rethrowing the InterruptedException. Since we are throwing the exception, we can rely on the caller to set the bit if they swallow it and need to preserve it.
This was introduced in #36631