[purushah]

Linked issue: N/A (follow-up to the action-key fix that landed through #1100)

Purpose of change

Durable action-state keys used to derive the action segment from Action.hashCode(). For Java actions that hash folds in JavaFunction's Class<?>[] parameterTypes, and Class.hashCode() is a per-JVM identity hash, so every key changed on restart and recovery never replayed completed actions. The fix, deriving the segment from the plan-unique action.getName(), is already on main through #1100, which was stacked on this branch.

This PR carries what remains: a regression test that reproduces the restart failure, removal of a test that could not detect it, and two clarifications to the upgrade guidance #1100 added.

Behavioral Semantics

Behavioral contracts

1. Two Actions with the same name whose JavaFunction parameter types are distinct Class objects, loaded by different class loaders, produce the same state key.
2. Recovery reuses completed results for an action only while its name is unchanged; renaming an action makes its recorded results unreachable and it executes again on the next recovery.

Failure behavior

Nothing in this change raises or changes a runtime path. The test skips, rather than fails, in the rare case that the two Class objects happen to receive equal identity hashes, because there is then nothing to discriminate.

Tests

Contract	Test
1, key stable across class loaders	ActionStateUtilCrossClassLoaderTest, new
2, renaming semantics	documented; pinned indirectly by ActionStateUtilTest.testActionUUIDSegmentDerivesFromActionName, already on main

ActionStateUtilCrossClassLoaderTest loads an Event subclass through two isolating class loaders, which yields two distinct Class objects with different identity hashes, the same effect a JVM restart has on JavaFunction.hashCode(). The loader redefines only the subclass and delegates everything else to the parent, so Action's signature check against Event still passes. Verified against main with the action segment temporarily switched back to Action.hashCode(): the test fails on the action-UUID segment; with main as is, it passes.

ActionStateUtilTest.testSameActionNameYieldsSameKeyAcrossInstances is removed. Both instances share the same Class objects inside one JVM, so it passed before the fix too.

The earlier cross-JVM test that launched two java processes is not carried over. As noted in review, separate JVMs do not guarantee different identity hashes and the test passes on JDK 17 with the old derivation restored, so it added CI time without discriminating the bug.

JAVA_HOME=<jdk17> mvn test -pl runtime -am -Dtest='ActionStateUtil*': 29 tests, 0 failures. mvn spotless:check under JDK 17 passes.

API

No public API or runtime change.

Documentation

• doc-needed
• doc-not-needed
• doc-included

Two edits to the upgrade hint under Exactly-Once Action Consistency in deployment.md: the incompatible key-format change is dated to Flink Agents 0.4, and a sentence states that an action's recorded results survive a code change only while its name is unchanged.

Was this patch authored or co-authored using generative AI tooling?

• Yes
• No

Generated-by: Claude Code (Claude Fable 5.1)

🤖 Generated with Claude Code

[rob-9]

thanks! these address my earlier comments.

everything looks good. I've added two non-blocking suggestions below about documenting future action changes and qualifying the separate-JVM test claim.

[wenjin272]

Thanks for working on this, and apologies—I mistakenly merged #1100 before reviewing and merging this PR, even though it was based on your changes. I preserved your Co-authored-by attribution in the squash commit.

The core action-name-based identifier change is already on main through #1100. Could you rebase this PR onto the latest main and keep the remaining test updates, adapting them to the new key encoder API? We can retain the upgrade guidance already added by #1100 and clarify that the incompatible state-format change starts with Flink Agents 0.4, rather than adding a separate upgrade note.

[purushah]

Rebased onto main. The action-name derivation is dropped from this PR since #1100 carries it, thanks for preserving the attribution. What remains: the class-loader regression test adapted to ActionStateKeyEncoder via ActionStateTestUtils, removal of the same-JVM test that could not detect the bug, and two edits to the upgrade hint from #1100: the format change is dated to 0.4, and a sentence covers action renaming. The cross-JVM test is not carried over, see the thread on it.

[wenjin272]

Thanks for the rebasing. LGTM