are memories created with the mem0ai python library and openmemory/api mcp server compatible (and should they be visible to the openmemory/ui server)?

[tcrisall]

Hello,
I've been playing with an on-prem installation of openmemory in my kubernetes lab. I've successfully got openmemory/ui working with openmemory/api storing memories in a qdrant instance. The openmemory/api (mcp server) is talking with my on-prem ollama for both LLM and embedding model. All of this works and I'm able to create memories via the ui and verify their existance with the qdrant dashboard.

With all this 'working', I've now installed a mem0 pipeline in Open-Webui which is also connected to the same qdrant instance and leveraging the same on-prem ollama. Again, I have memories working in Open-Webui, I can confirm they exist with qdrant dashboard and memories are clearly showing up in conversations. What I have NOT been able to achieve is seeing the memories created by the pipeline with the openmemory/ui. I have confirmed that the memories are stored in the same catalog, the user_id of all memories is consistent. I'm populating all of the same metadata fields (the records look exactly alike). I have noticed that OpenWebui is able to bring up memories I've created using openmemory/ui but again, the ui can't see the memories created by the plugin.

Sorry for such a long winded paragraph, I'm very new to this so I'm poking, playing and learning. I would very much appreciate anyone's insight into this.

For what it's worth, the pipeline I'm using is at https://github.com/cloudsbird/mem0-owui . I've made changes to update the version of the python library to the newest as well as added metadata for mcp_client and source_app to the add memory operation.

Thanks to anyone who takes the time to read this, and thanks to all of you who have created such a neat project.

p.s. I should also mention that I have an on-prem version of helicone wired into all of this sitting in front of the ollama server so I get insight into most of the traffic (everything except the embedding calls).

[onestardao]

looks like an interop/catalog mismatch between mem0’s write path and the openmemory UI. quick checks:

1. confirm mem0 and openmemory/ui are writing to the same catalog/collection and same user_id
2. verify the memory records include the same metadata keys (source_app / mcp_client / vector field) the UI expects
3. query the store directly (qdrant/openmemory) to confirm vectors + ids exist for those records
4. check openmemory/ui logs for incoming sync events or filters that might hide plugin-created entries
5. if everything looks right, trigger a manual resync/reindex and watch traffic (helicone) to compare what mem0 vs UI sends

want the short checklist + resync command I use for this class of issue? I can paste it.