Fix bundle finalizer callbacks for SDF

[aIbrahiim]

Fixes: #38710
Successful run: https://github.com/apache/beam/actions/runs/28039649218/job/83002285984?pr=39075

These tests were failing:
SplittableDoFnTest.testBundleFinalizationOccursOnBoundedSplittableDoFn SplittableDoFnTest.testBundleFinalizationOccursOnUnboundedSplittableDoFn
as they often timed out after 900 seconds with the job still in RUNNING

The tests use a Splittable DoFn that registers a BundleFinalizer callback and keeps checkpointing with resume() until that callback runs. If the callback never runs, the DoFn never outputs, the pipeline never finishes, and the test hits the timeout. The problem was in the Dataflow legacy streaming worker. Bundle-finalizer callbacks were only run when Windmill sent the finalize IDs back on a later work item (via source_state.finalize_ids or applied_finalize_ids in GetWorkResponse). Windmill documents that this is best effort, the commit can succeed but the IDs may never come back.

For Splittable DoFns with many resume() checkpoints, each step does a new commit and waits for the callback on the next work item and on real Dataflow those IDs often dont come back, so callbacks never run and the job hangs.

This got worse after bundle finalizer support was added for the streaming legacy worker:
#37723 Added bundle finalizer support to the non portable Dataflow worker and streaming ValidatesRunner tests were first excluded because they were still failing.
#37954 moved applied_finalize_ids handling and reenabled UsesBundleFinalizer tests for legacy streaming ValidatesRunner and hat helped some cases, but SDF tests could still hang on real Dataflow when finalize IDs were not echoed back.

#38287 in my previous PR I tried to stabilize SplittableDoFnTest on the test side (thread safety, timeouts) but that did not fix the worker behavior.

So when Windmill acknowledges a successful commit (CommitStatus.OK), we now run bundle finalizer callbacks right away, using the finalize_ids from that commit then a successful commit ACK means the state was persisted and it is same idea as applied_finalize_ids, but without relying on a later best effort GetWork.

---

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, 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 with bundle finalizer callbacks in the Dataflow streaming worker. By ensuring that finalize IDs are captured during the commit process and subsequently queued for application, the changes ensure that bundle finalization logic is correctly triggered upon successful work completion.

Highlights

• Bundle Finalizer Callbacks: Updated the streaming worker to correctly queue and process bundle finalizer IDs from successful commits.
• CompleteCommit Model Update: Extended the CompleteCommit class to include finalizeIds, ensuring this information is propagated through the commit pipeline.

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

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 updates the CompleteCommit class to include finalizeIds extracted from the commit request. The StreamingDataflowWorker is updated to queue these applied finalize IDs upon a successful commit status. Additionally, StreamingApplianceWorkCommitter now passes the finalize IDs when creating a CompleteCommit. A trivial modification was also made to trigger the Dataflow Streaming post-commit tests. There are no review comments, 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.

[github-actions]

Assigning reviewers:

R: @shunping added as fallback since no labels match configuration

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

[aIbrahiim]

@damccorm @Abacn

[Abacn]

R: @arunpandianp could you please take a look? FYI the tests becomes very flaky in recent weeks

[github-actions]

Stopping reviewer notifications for this pull request: review requested by someone other than the bot, ceding control. If you'd like to restart, comment assign set of reviewers

[Abacn]

@aIbrahiim could you please explain a bit what was the cause of the flaky tests

[aIbrahiim]

@aIbrahiim could you please explain a bit what was the cause of the flaky tests

Yes sure, just updated the PR

[Abacn]

R: @acrites

[Abacn]

currently prefer #39092 just disabling the tests at the moment, since Dataflow classic streaming runner SDF support not completed yet

[acrites]

In general, I don't quite think this idea will work. The main reason for needing finalize id's is that Windmill can return Commit status OK before the actual results are durably persisted in the backend. So if the persistence were to fail (e.g. backend worker gets restarted) sometime after the CommitWork returned OK but before the results were persisted, we would incorrectly run the finalize callback.

I agree with your analysis of the flakiness though. It looks like the tests keep trying to process the element (claiming a new offset of the restriction) up to 3000 times expecting the finalization callback to happen at least once. What's weird is, I'd expect this to be equally flaky on the (streaming) portable worker too.

[aIbrahiim]

In general, I don't quite think this idea will work. The main reason for needing finalize id's is that Windmill can return Commit status OK before the actual results are durably persisted in the backend. So if the persistence were to fail (e.g. backend worker gets restarted) sometime after the CommitWork returned OK but before the results were persisted, we would incorrectly run the finalize callback.

I agree with your analysis of the flakiness though. It looks like the tests keep trying to process the element (claiming a new offset of the restriction) up to 3000 times expecting the finalization callback to happen at least once. What's weird is, I'd expect this to be equally flaky on the (streaming) portable worker too.

@acrites Thanks for taking a look, and yeah you’re right i took a look again and yes running the callback on CommitStatus.OK is not safe. I misunderstood that OK can come back before the results are actually durable, so if persistence fails after that we could finalize too early. That’s why the finalize-id round trip exists so this approach isn’t going to fix it

Yeah I'm glad that the flakiness analysis still lines up and on the portable side, I think it’s less flaky because finalization goes through the Fn API FinalizeBundle path instead of the Windmill applied_finalize_ids best-effort echo. Also the V2 streaming ValidatesRunner suite excludes UsesBoundedSplittableParDo, so that bounded SDF finalizer test doesn’t even run there

[acrites]

What's weird is that the FnAPI FinalizeBundle path should have the same problem - it still relies on Windmill sending best effort finalize ids.

[aIbrahiim]

What's weird is that the FnAPI FinalizeBundle path should have the same problem - it still relies on Windmill sending best effort finalize ids.

Yes I think on Dataflow the Fn API FinalizeBundle path still depends on Windmill sending applied_finalize_ids, so it should have the same best-effort limitation and that part of my explanation was wrong

So I’m less sure why portable isn’t showing the same flake. Maybe the SDF execution path is different enough or maybe V2 just doesn’t run the same tests as often (e.g. bounded SDF is excluded from the V2 streaming ValidatesRunner suite). Or maybe it is flaky there too and we just haven’t noticed as much