Editing a message inside a thread duplicates it on every save and reorders the thread by edit recency

[chivnerd]

Describe the bug

Editing a message that is part of a thread appends a duplicate of the message on every save, with the duplicates ordered by most-recently-edited at the end of the thread. The signature matches a kind-40003 edit event being rendered as its own row: each save publishes a new event with a fresh created_at carrying the full new body — one duplicate per save, sorted to the end.

Steps to reproduce

1. Open a thread in a channel.
2. Message menu → Edit on a message in the thread; change the text; save.
3. Repeat the edit — one duplicate appears per save.

Observed on a downstream desktop build pinned to exactly a9dd4d3 plus a branding-only patch (no message/thread code changes), so the pipeline is vanilla Buzz at that commit. The exact surface (channel thread panel / home inbox / agent conversation / DM) and authorship (human vs agent-attributed) are not yet narrowed.

Expected behavior

The message updates in place with an "edited" indicator; thread ordering unchanged; no new rows.

Version and platform

• Buzz version: a9dd4d3 (Tauri desktop)
• OS: macOS (arm64)

Logs / additional context

At the pinned commit we verified clean, so the duplicate-producing path is still unidentified:

• NIP-10 ignores unmarked e tags, so edits never get a thread_metadata row and get_thread_replies never returns them.
• Every thread surface traced (channel thread panel, project panels, huddle transcript, home inbox, mobile) formats through formatTimelineMessages / formatTimeline, which never render kind 40003 as a row.
• Live-subscription aux merges dedupe by id; useEditMessageMutation patches caches in place.

Happy to attach a get_thread_replies payload capture for the affected thread once reproduced — kind-40003 events in that payload would point at relay-side thread membership rather than client rendering.

[UgaTheDev]

Taking a look at this one — reproducing now, will follow up with a fix and a regression test.

[UgaTheDev]

Update after tracing the desktop side (HEAD 8953cbf): I could not find a client path where a kind:40003 edit becomes its own thread row. mergeMessages dedupes by id, formatTimelineMessages treats 40003 purely as an overlay and keeps the original's created_at, and threadPanel sorts on that — running two 40003 edits of a middle reply through the real helpers yields one row in its original position. That matches your own "clean at a9dd4d3."

The one client path I found that produces exactly the reported signature (fresh event, new created_at, full body, appended to the thread, once per save) is in MessageComposer.submitMessage: the edit branch requires both an armed edit target and an onEditSave handler, so if a surface arms a target without wiring onEditSave, submit falls through to the normal send path and publishes the edited body as a brand-new reply, and edit mode never clears. In current wiring every surface passes both, so I can't prove that's what you hit.

The discriminating question: in your get_thread_replies capture, are the duplicate events kind 40003 or kind 40002 with the edited body? If 40002, the composer fall-through is the mechanism and I have a guard ready (fix/7701-thread-edit-duplicate on my fork). If 40003, the client pipeline is fine and this is relay-side thread membership, which I'd leave to the relay folks.

[UgaTheDev]

Following up since my last note. To recap what I ruled out on desktop: mergeMessages dedupes by id, formatTimelineMessages treats a 40003 edit purely as an overlay and keeps the original's created_at, and threadPanel sorts on that. Running two 40003 edits of a middle reply through the real helpers gives one row in its original position, matching "clean at a9dd4d3." The only path I found that produces the reported signature (a fresh event with a new created_at and the full body, appended once per save) is MessageComposer.submitMessage falling through to the normal send path when a surface arms an edit target without wiring onEditSave. But every current surface wires both, so I can't confirm that's the actual mechanism here.

I could not reproduce the duplication on desktop at HEAD 8953cbf with the real client pipeline. To make progress I need:

• Client: desktop or mobile
• OS and app/build version
• Exact steps to reproduce
• Whether the duplicate appears for other members viewing the thread, or only on the editor's own client
• If you have a relay capture: are the duplicate events kind 40003, or kind 40002 with the edited body? If 40002, I have a guard ready on fix/7701-thread-edit-duplicate; if 40003, this looks like relay-side thread membership rather than a client bug.

Without a repro or those details I'm stepping back from this one for now, so it doesn't look claimed with no visible progress. Happy to pick it back up as soon as a repro turns up.