sangkyoonnam opened a new issue, #1179: URL: https://github.com/apache/flink-agents/issues/1179
### Search before asking - [x] I searched in the [issues](https://github.com/apache/flink-agents/issues) and found nothing similar. ### Description The Python runtime records a failed tool call as the text it shows the model in `responses`, with `success` false and the diagnostic in `error` (`_record_tool_response` and `_record_execution_exception` in `tool_call_action.py`). Java's `ToolResponseEvent.fromEvent` wraps every non-map response in `ToolResponse.success(v)` (`ToolResponseEvent.java:86`) and ignores `success`. A Java caller reconstructing such an event, including an Event Log reader following the guidance in `EventLogRecordJsonDeserializer`, gets a response whose `isSuccess()` is true and `getError()` is null. Java's `ChatModelAction`, the one built-in Java consumer, checks the outer `success` flag and would send the literal text `null` to the model for that call; no built-in wiring routes a Python event to it today, and the built-in Python chat loop doesn't go through this path. `toString()` also throws on these events. Python doesn't set `timestamp`, and `toString()` calls `getTimestamp()`, which calls `longValue()` on the missing value. It also prints `success=true` whatever the event holds. #956 set out that the Java/Python bridges preserve explicit tool success, failure and error details; this reconstruction path still drops the failure. A fix can key off `success` rather than inspect the payload, and leaves the wire format unchanged, which is what #956 asked for. This also sits on the path #1125 agreed on: its normalizer at `Event.fromJson` maps each built-in type to its existing `fromEvent`, so once it lands every Python `ToolResponseEvent` crossing the bridge would go through here. @yunfengzhou-hub, happy to fold the fix into that work if you'd rather. The cross-language snapshot only covers successful responses today. Expected: a textual response emitted by Python's tool action with `success[id]` false becomes an error response whose `getError()` is that text, the diagnostic stays in `event.getError().get(id)`, and `toString()` works for events without a timestamp. `getTimestamp()` would still throw for them; whether Python events should carry a timestamp is a separate API question, so I'd leave it out. ### How to reproduce ```java // A Python ToolResponseEvent for a tool that raised: // "responses": {"call_dddd": "Tool `get_weather` execute failed."}, // "success": {"call_dddd": false}, // "error": {"call_dddd": "ValueError: boom"} ToolResponseEvent event = ToolResponseEvent.fromEvent(Event.fromJson(pythonJson)); event.getResponses().get("call_dddd").isSuccess(); // true event.getResponses().get("call_dddd").getError(); // null event.toString(); // NullPointerException ``` ### Version and environment main (`1618728b`). JDK 21, OS independent. Java API; the Python side is unchanged. ### 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]
