Fix DoFnInvoker cache collision for generic types

[Eliaaazzz]

Fixes #37351

Description

This PR addresses a critical bug in the ByteBuddyDoFnInvokerFactory where the caching mechanism for generated DoFnInvoker classes failed to distinguish between different generic instantiations of the same DoFn class.

1. The Problem: Cache Collision on Generic Types

The previous implementation utilized a ConcurrentHashMap<Class<?>, Constructor<?>> to cache the generated invoker constructors. The cache key was solely the DoFn class itself.

In scenarios involving generic DoFn classes (e.g., class MyGenericFn<T> extends DoFn<T, T>), the raw class object is identical regardless of the type parameter T.

• Scenario: If a pipeline instantiates MyGenericFn<String> and later MyGenericFn<Integer>, the factory would generate an invoker for String and cache it.
• The Bug: When MyGenericFn<Integer> is requested, the factory hits the cache using the same MyGenericFn.class key and returns the String-specialized invoker.
• Consequence: This leads to runtime ClassCastException or incorrect Coder inference, as the bytecode for the invoker is specialized for the wrong type.

2. The Solution: Type-Aware Caching & Naming

This PR introduces a composite cache key and updates the class naming strategy to ensure full isolation between generic types.

A. Introduced InvokerCacheKey

I replaced the simple Class<?> key with a new static inner class InvokerCacheKey. This key encapsulates three components:

1. fnClass: The raw class of the DoFn.
2. inputType: The TypeDescriptor for the input element.
3. outputType: The TypeDescriptor for the output element.

By implementing equals() and hashCode() based on all three fields, we ensure that MyGenericFn<String> and MyGenericFn<Integer> map to distinct cache entries.

B. Unique Class Naming Strategy

ByteBuddy cannot define two different classes with the exact same name in the same ClassLoader. To support multiple generated invokers for the same raw DoFn class, I modified generateInvokerClass.

• Old Strategy: <DoFnClassName>$DoFnInvoker
• New Strategy: <DoFnClassName>$DoFnInvoker$<TypeHash>

The suffix now includes a hexadecimal hash derived from the input and output TypeDescriptors. This guarantees that the generated bytecode class names are unique for each generic instantiation.

Test Plan

I have added a regression test testCacheKeyCollisionProof to DoFnInvokersTest.java.

• Methodology: The test defines a local generic class DynamicTypeDoFn<T> and manually forces specific TypeDescriptor returns.
• Verification: It instantiates the DoFn twice (once for String, once for Integer) and asserts that the generated Invoker classes are not the same (assertNotSame).
• Result: The test passes with the fix (confirming distinct invokers are generated) and fails without it.

Existing tests passed:

• DoFnInvokersTest

---

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 @Eliaaazzz, 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 a significant bug in the ByteBuddyDoFnInvokerFactory that caused cache collisions when handling generic DoFn types. Previously, the factory would incorrectly reuse DoFnInvoker instances specialized for one generic type for another, leading to runtime errors. The solution involves a more granular caching mechanism that considers the DoFn's generic type parameters and a revised class naming convention for dynamically generated invokers, ensuring proper type isolation and preventing erroneous behavior.

Highlights

• Cache Collision Fix: Resolved a critical bug in ByteBuddyDoFnInvokerFactory where the cache for generated DoFnInvoker classes would return the same invoker for different generic instantiations of the same DoFn class, leading to ClassCastException or incorrect Coder inference.
• Enhanced Cache Key: Introduced a new InvokerCacheKey which is a composite key including the DoFn class, its input TypeDescriptor, and its output TypeDescriptor. This ensures unique cache entries for different generic types.
• Unique Class Naming: Modified the dynamic class naming strategy for generated DoFnInvoker classes to include a hash derived from the input and output TypeDescriptors. This prevents class name collisions in the ClassLoader when multiple generic instantiations of the same DoFn are used.
• Regression Test Added: A new regression test, testCacheKeyCollisionProof, has been added to DoFnInvokersTest.java to verify that distinct invokers are generated and cached for different generic types of the same DoFn.

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