GitHub user weiqingy added a comment to the discussion: [Feature] Sub-agent Resource for Flink Agents - Framework part
Hi @pltbkd, thanks for the detailed follow-up. Focusing strictly on the framework primitives for the initial PR sounds like a good approach. **SubagentCompatible marker:** Sounds good. We can use the compile-time `@SubagentCompatible` marker for now and reconsider runtime enforcement if it creates friction. **Non-blocking yield mechanics:** What I meant is that the wait itself should not require a thread. On the continuation path the Action already suspends without holding the mailbox thread: the continuation yields, and the operator re-queues the task, allowing other keys to interleave. What still consumes a thread is the wait, because the executor's current resume condition is a `Future` produced by its own submission. A wait-only callable therefore parks an async-pool thread purely as a placeholder. Generalizing that resume condition to a completion handle that the mailbox or another thread may complete would let a wait-only invocation consume a continuation but no worker thread. If a dedicated pool is the pragmatic solution for this iteration, I have no objection, provided nested calls cannot exhaust it. **Timeout and cancellation:** Agreed on avoiding a caller-controlled `Future` interface in this iteration. Since an InternalSubagent Action generally cannot be interrupted mid-flight, framework-managed deadlines and cooperative checks between Actions through `SubagentRunnerContext` seem sufficient for the initial scope. **External idempotency:** Deterministic session and call IDs make sense as the invocation identity. Reading @alnzng's example, the step that actually closes the completed-but-not-checkpointed window is reconciliation before resending, rather than the IDs alone. It therefore seems worth naming reconcile-before-resend explicitly as a requirement of the external-subagent support framework. **Async interface:** Given the Python and JDK < 21 constraints, unifying on asynchronous result semantics sounds reasonable. I also agree that surfacing the durable-callable factory as the caller-facing method exposes an execution mechanism, and is not an ideal name for that surface. If possible, the public API could keep an invocation-oriented operation on the sub-agent surface, with `DurableCallable` staying the durability and batch-execution mechanism underneath rather than something a caller reaches for. **Templates:** Agreed on establishing the framework primitives before higher-level templates such as SupervisorAgent. GitHub link: https://github.com/apache/flink-agents/discussions/909#discussioncomment-17860229 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
