wenjin272 opened a new issue, #1372: URL: https://github.com/apache/flink-agents/issues/1372
### Search before asking - [x] I searched existing issues and found no issue tracking this shared-cache commit boundary. ### Description A child Action in `ctx.chat(...)` can persist its caller's unfinished memory updates. If a checkpoint captures those updates together with the unfinished parent Action, recovery replays the parent from the beginning and can apply the updates twice. `ChatSubgraphDefinition.newInvocation()` passes the parent's sensory and short-term memory stores into the chat graph. When a child Action completes, the framework calls `persistMemory()`, which flushes the shared cache to Flink state. This includes writes made by the parent before the chat call, even if the child itself never modifies memory. The parent is still unfinished and remains eligible for replay. Retaining ActionState call results does not prevent the problem: reusing a completed chat result does not skip the ordinary parent code that ran before that call. Expected behavior: checkpointed memory and Action replay must have consistent commit boundaries. Completing a child Action must not make an unfinished parent's updates durable in a way that causes them to be applied again on recovery. The fix should align shared-memory commits with the root Action's replay boundary while preserving the child graph's access to its caller's uncommitted memory. This was reported in [the review of #1354](https://github.com/apache/flink-agents/pull/1354#issuecomment-6734741043). The memory-sharing behavior predates that PR and already affects continuation execution. Removing the pre-barrier drain exposes the checkpoint window on the low-JDK parallel engine as well. Internal subagents currently use isolated memory stores whose `persistCache()` is a no-op, so they do not flush the parent's cache through this mechanism. ### How to reproduce Use a parent Action with the following sequence: 1. Read a short-term memory counter initialized to `0` and write `counter + 1`. 2. Await `ctx.chat(...)` and let a child Action complete, flushing the shared cache. 3. Block the parent on another asynchronous call. 4. Complete a checkpoint while the parent remains unfinished, then fail and restore the job. 5. Allow the parent to replay and finish. Expected counter: `1`. Actual counter: `2`, because the checkpoint already contains the first increment and the parent repeats it during replay. Regression coverage should exercise both continuation and low-JDK parallel execution with RocksDB, including retained ActionState call results. ### Version and environment - Reviewed PR #1354 head: `9816a83341c9d00d606d9005301a3bb6a619f038`. - The reviewer reports reproducing this with RocksDB on both execution paths, including with ActionState logs retained. - The shared-cache and commit call paths have been confirmed in source; the reported runtime reproduction has not yet been independently rerun for this issue. ### Are you willing to submit a PR? - [x] I'm willing to submit a PR! -- 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]
