CryoThrust commented on issue #11304:
URL: https://github.com/apache/seatunnel/issues/11304#issuecomment-5551084890
One API-contract detail is worth making explicit before implementation: the
current Mem0 API reference documents the additive pipeline as an asynchronous
`POST /v3/memories/add/` operation. It accepts `messages` plus at least one
scope identifier (`user_id`, `agent_id`, `app_id`, or `run_id`) and returns an
`event_id`; completion is observed separately via `GET /v1/event/{event_id}/`.
This is materially different from treating an upsert as a synchronous
per-record write.
For the Phase 1 sink, the design should therefore choose and document one of
these boundaries:
- acknowledge a record when the add request returns 2xx (`accepted`,
at-least-once, with event polling outside the sink); or
- retain the record until the event reaches a terminal success state
(`completed`, stronger delivery claim but requires polling/state management).
The API reference also describes this endpoint as additive-only (no
UPDATE/DELETE in that operation). If delete support remains in scope, it should
name the exact documented delete endpoint and its acknowledgement semantics
separately rather than presenting `upsert` as a single generic Mem0 operation.
The connector should reject an unverified endpoint/capability at startup
instead of silently mapping a delete to the additive API.
--
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]
