weiqingy commented on issue #983: URL: https://github.com/apache/flink-agents/issues/983#issuecomment-5262184339
@wenjin272 Binding the context to the `MemorySet` looks like the better boundary, and cheaper than it first appears. `add`, `get`, `search` and `delete` already take `memory_set` as their first parameter on `BaseLongTermMemory`, so nothing new needs threading. Only the source of the key changes. That also settles my submit-time idea, which would have needed `durable_execute_async` to learn about LTM context. Java has to move in the same change rather than a follow-up, I think. Its ops all delegate into the same Python object, and the bridge rebuilds the Python set from the name alone: `to_python_memory_set` returns `MemorySet(name=name)`, its docstring noting that only `name` is ever read (`python_java_utils.py:388-393`). So once the Python ops take the key off the set, every Java-originated call arrives without one, and splitting the work would mean either breaking Java or keeping a `self.key` fallback that leaves that path racy. `getMemorySet` there is a pure local factory (`Mem0LongTermMemory.java:55-61`), so it would need the key at construction and the bridge would need to carry it. One thing I would still like your read on. `delete_memory_set` takes a name rather than a `MemorySet` (`mem0_long_term_memory.py:441`), reads `self.key` at :450, and passes it to mem0 as `agent_id` at :457, so binding the set cannot reach it. Should it take a `MemorySet` too, or is deleting a whole set meant to stay mailbox-only? Nothing caches a set today, `get_memory_set` returns a fresh one and the only callers are tests. Would it be worth recording the mailbox thread id in `switch_context` and asserting it in `get_memory_set`? That catches construction off the mailbox thread, though not reuse across actions. I will open the race issue and take the first pass at the fix, leaving `delete_memory_set` as it is until you weigh in. -- 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]
