weiqingy commented on issue #723: URL: https://github.com/apache/flink-agents/issues/723#issuecomment-4607370512
@joeyutong Thanks for the detailed write-up and the repro. I traced both code paths and they line up with what you describe: - _update_tool_call_context keys the stored dict by a UUID (tool_call_context[initial_request_id]) at chat_model_action.py:77-84. - _save_tool_request_event_context stores "initial_request_id": initial_request_id (a UUID) keyed under another UUID at chat_model_action.py:96-102. And FlinkMemoryObject.set() passes the raw Python value straight to the Java MemoryObjectImpl.set() via Pemja (flink_memory_object.py:68), so anything Pemja can't materialize ends up as a PyObject/PyJObject wrapper inside the checkpointed Java state — consistent with the SIGSEGV in JcpPyObject_FromJObject on restore. One thing that may be worth folding into the scope: the same _save_tool_request_event_context dict also stores "output_schema": output_schema at chat_model_action.py:100, and OutputSchema is a Pydantic BaseModel (api/agents/types.py:25). That has the same non-materialization problem as UUID, so it looks like a second instance of this class of bug in the built-in path — not just the two ID fields. A small note on the suggested fix: in _update_tool_call_context the UUID is used as a dict key, not just a value, so normalizing would need to cover keys too (e.g. str(initial_request_id)), otherwise the Pemja wrapper just moves from the value side to the key side. On the broader contract piece — do you have a preference between (a) only documenting that Python memory values must be recursively checkpoint-stable, vs. (b) validating at set() time and rejecting non-stable values with a clear error before they reach state? Option (b) turns a checkpoint-time JVM crash into an early, debuggable failure, but it's a behavior change, so it seems worth getting other opinions before settling on it. WDYT? -- 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]
