rob-9 commented on code in PR #1094: URL: https://github.com/apache/flink-agents/pull/1094#discussion_r3999844538
########## runtime/src/test/java/org/apache/flink/agents/runtime/actionstate/CrossJvmKeyStabilityTest.java: ########## @@ -0,0 +1,94 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.flink.agents.runtime.actionstate; + +import org.apache.flink.agents.api.InputEvent; +import org.apache.flink.agents.plan.actions.Action; +import org.junit.jupiter.api.Test; + +import java.io.BufferedReader; +import java.io.InputStreamReader; +import java.nio.charset.StandardCharsets; +import java.nio.file.Path; +import java.util.ArrayList; +import java.util.List; + +import static org.junit.jupiter.api.Assertions.assertEquals; +import static org.junit.jupiter.api.Assertions.assertNotNull; + +/** + * Cross-JVM regression test for the original failure (review): durable-state keys must be identical + * when the same action is keyed from two DIFFERENT JVM processes, which is what recovery after a + * process restart looks like. The in-JVM tests in {@link ActionStateUtilTest} pin the derivation; + * they cannot catch a hash that folds in {@code Class.hashCode()}, because identity hashes are + * stable within one JVM — the pre-fix bug only manifests across processes. + */ +class CrossJvmKeyStabilityTest { + + /** Entry point run in the child JVMs: prints the state key for a fixed action and event. */ + public static final class PrintKey { + public static void main(String[] args) throws Exception { + Action action = new NoOpAction("cross-jvm-action"); + InputEvent event = new InputEvent("cross-jvm-input"); + // Fixed key/seqNum/maxParallelism so the only possible variation is the action UUID. + System.out.println( + "STATE_KEY=" + + ActionStateUtil.generateKey("cross-jvm-key", 5, action, event, 8)); + } + } + + @Test + void sameActionYieldsSameKeyAcrossSeparateJvms() throws Exception { + String first = keyFromFreshJvm(); + String second = keyFromFreshJvm(); + assertEquals( Review Comment: nit : with the old hash calculation restored, this test still passes on a JDK 17 setup. separate JVMs don't guarantee different identity hashes. the class-loader test catches the old bug, so my earlier request is covered. but could we soften the PR description's claim that this test fails before the fix? ########## docs/content/docs/operations/deployment.md: ########## @@ -104,6 +104,10 @@ The same persisted action state is also used by fine-grained durable execution. See [Action State Store Configuration]({{< ref "docs/operations/configuration#action-state-store" >}}) for configuration options. +{{< hint warning >}} +**Upgrading**: Action state keys are derived from the action name since Flink Agents 0.4. Action state recorded by earlier versions is not consulted after the upgrade. Upgrade from a stop-with-savepoint taken after the job is idle with no pending actions, and do not restore the upgraded job from an older checkpoint; otherwise actions completed since that checkpoint are executed once more. Review Comment: could we also explain what this means for future action changes? keeping the name means recovery can reuse results from the prev implementation, while renaming it makes those results unreachable and can cause re-execution. the release upgrade guidance looks good; these rules would help users update their own agents too. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
