wenjin272 commented on issue #1322: URL: https://github.com/apache/flink-agents/issues/1322#issuecomment-6412231765
Thanks for offering to work on this! No one is currently working on the second item, so you're very welcome to take it on. I think this issue is part of a broader question about distinguishing application-level failures from framework faults at two boundaries: | Boundary | Expected handling of framework faults | What can go wrong | | --- | --- | --- | | ToolCallAction's failure-to-response conversion | Propagate the fault to the runtime so the job can fail and recover, preserving the original cause. | The fault becomes an ordinary tool failure response, allowing execution to continue or obscuring the original cause with a later error. | | Durable execution's outcome recording | Propagate the fault without recording it as a terminal call outcome. | Recovery replays the recorded failure instead of retrying the operation, potentially causing repeated failovers even after the underlying fault is gone. | The second item in this issue directly concerns the first boundary. However, the distinction between application failures and framework faults should be consistent across both boundaries, and ordinary tool calls can encounter similar problems too. An explicit exception type may be part of the solution, but I haven't settled on the design yet. Before choosing a subagent-specific implementation, I'd like us to discuss the shared semantics and how they relate to the existing `UncapturableException` mechanism. This doesn't necessarily mean fixing both boundaries in one 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]
