wenjin272 commented on issue #1067: URL: https://github.com/apache/flink-agents/issues/1067#issuecomment-5460609142
Thanks for raising this. I agree that durable human approval could be a strong use case for Flink Agents. However, this affects the public Action contract, runtime scheduling, external signal routing, and checkpoint/recovery semantics, so I think we should agree on a concrete design in a Discussion before starting implementation. In particular, the current runtime introduces several questions that an `await_approval` API alone would not answer: - An unfinished `ActionTask` keeps the key in flight, and later events for the same key are buffered. An approval delivered as an ordinary keyed input event could therefore be queued behind the Action it needs to resume. - A long-lived pending key may affect watermark progression and end-of-input handling. - Checkpoints persist operator-managed task state, but not an in-memory Java stack or Python coroutine. Recovery therefore needs an explicit persisted approval state machine and deterministic re-entry, rather than assuming execution resumes at the original call site. - #1016 aligns part of the Java/Python recovery model, but does not yet define durable Action suspension and external resumption. Since this would introduce significant changes to the Action API and runtime semantics, I think we should discuss and agree on the design before moving toward implementation. Could you please open a GitHub Discussion with a concrete design proposal so the community can review it and align on the approach? -- 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]
