yunfengzhou-hub commented on PR #1138: URL: https://github.com/apache/flink-agents/pull/1138#issuecomment-5776306019
> Thanks for picking this up. Before we get into line-by-line review, could we open a discussion for the runtime model? This PR settles a few things #909 left open, and they affect most of the operator changes. > > The three I'd like agreement on: > > 1. Where in-flight call state lives across a checkpoint. Right now it's only on the heap and rebuilt when the parent replays, but child tasks are checkpointed before the parent is re-enqueued. On restore the child can run first, find no status, and the job loops. > 2. Whether the parent should wait on a `ContinuationActionExecutor` thread. Children use the same pool, so enough concurrent calls on one subtask can starve it. > 3. What "done" means for a child with more than one action. Replay only re-sends the child's output events, so a chained child comes back with partial output after failover. > > I have more detailed notes and am happy to share them once the direction is set. @purushah Thanks for the comment. Worth aligning on these before this moves further. The preview does have some known persistence gaps that we're addressing. **1. In-flight state and recovery.** We'd like to settle the principle first and get your read. A sub-agent call inherits durable execution's consistency model: - Without ActionState, an in-flight call tolerates recomputation and takes the final result. - With ActionState, the call is consistent but requires the request to be replayable; there is no reconcile mechanism, and anything needing reconcile belongs in durable execution. Mechanically, the parent's initiation and the child action's start each create a sub-agent call record, the later one linking to the earlier. On failover: without ActionState, in-flight calls are cancelled and re-run; with ActionState, the replayed action records serve as a reconciler for the call — when the parent has initiated but not completed, its request is matched against the persisted action records, completed actions are skipped and their results reused (including an already-produced OutputEvent, the sub-agent's response), and only the unfinished child actions re-run. Consistency therefore still rests on durable execution. I can write the full plan up separately if that's easier to react to. **2. Shared continuation executor.** The call awaits on the async pool, so it does hold async threads; under heavy parallel fan-out where the children also need async capacity, this can block. We expect large fan-out to be rare, so the near-term guidance is to raise the async thread count, with auto-scaling as a later option. **3. Multi-action child "done".** A call completes when all actions in its sub-agent scope quiesce — the same condition the main agent uses to finish a record: every output action is an OutputEvent and none is pending. Consistency follows point 1. --- We'd like to continue discussions in this PR or #1137, given that after #909 we have created an umbrella issue for sub-agent mechanism to better track discussions and development in each child issue. What do you think? -- 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]
