GitHub user weiqingy added a comment to the discussion: Design proposal for #1066: dry-run / replay via savepoints
Thanks for checking each of these against the runtime. The narrower scope looks reasonable. Two details may be worth settling before we treat the v1 shape as agreed. First, could seeding the replay action-state store cause completed production records to match the candidate Action and take the reuse branch, so the changed logic never runs? The action key hashes the action name, trigger conditions, and a descriptor covering only the method signature (`ActionStateUtil.java:224-228`, `Action.java:112-113`, `JavaFunction.java:100-103`), not the method body, prompt, model, or action config. Would a fresh replay-only store, or just leaving the backend unset, be safer than seeding it? Second, does replay need to pin max parallelism? I raised that one, and I think I pointed it in the wrong direction. In Flink 2.3.0 a derived value lets restoration adopt the savepoint's max parallelism, whereas an explicitly configured mismatch fails restore, and `allowNonRestoredState` does not bypass that check. Would a stable operator UID with inherited max parallelism be the safer prerequisite? GitHub link: https://github.com/apache/flink-agents/discussions/1069#discussioncomment-18261621 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
