Skip to content

fix(cli): preserve attachments when editing messages (issue 3022) - #3062

Open
ijoukov wants to merge 1 commit into
block:mainfrom
ijoukov:agent/preserve-cli-edit-attachments
Open

fix(cli): preserve attachments when editing messages (issue 3022)#3062
ijoukov wants to merge 1 commit into
block:mainfrom
ijoukov:agent/preserve-cli-edit-attachments

Conversation

@ijoukov

@ijoukov ijoukov commented Jul 27, 2026

Copy link
Copy Markdown

Summary

Fixes buzz messages edit so editing message text preserves the message’s effective attachment state
instead of silently removing attachments.

Buzz edit events replace both content and attachment metadata. The CLI previously emitted kind
40003 edits without imeta tags or the Markdown references used to render attachments, causing
existing attachments to disappear.

This change:

  • Resolves the original message and its latest kind 40003 edit before publishing another edit.
  • Preserves the complete effective imeta attachment set by default.
  • Preserves attachment Markdown references, including labels and spoiler formatting.
  • Synthesizes missing references when content and metadata have drifted.
  • Avoids duplicate references when the caller already included one.
  • Adds --clear-attachments as the explicit way to remove attachments.
  • Ensures later edits do not resurrect attachments after they have been cleared.

The SDK’s existing edit builder remains unchanged; a new builder variant accepts the complete
attachment set.

Related issue

Fixes #3022

Testing

Automated:

  • cargo test -p buzz-sdk -p buzz-cli — 524 tests passed
  • cargo clippy -p buzz-sdk -p buzz-cli --all-targets -- -D warnings
  • cargo fmt -p buzz-sdk -p buzz-cli
  • git diff --check

Functional Docker smoke test using Postgres, Redis, MinIO, and a locally running relay:

  1. Sent a message with a PNG attachment.
  2. Edited only the text and verified the attachment metadata and Markdown reference were preserved.
  3. Edited the message again and verified the latest attachment state remained intact.
  4. Edited with --clear-attachments and verified attachments were removed.
  5. Edited once more and verified cleared attachments were not resurrected.

The full just ci gate was not completed locally because this Linux environment lacks the GTK/WebKit
system libraries required by the desktop Tauri checks. The affected CLI and SDK checks above pass.

@ijoukov
ijoukov force-pushed the agent/preserve-cli-edit-attachments branch from 5d1ca9a to a4580ac Compare July 28, 2026 03:59
@ijoukov
ijoukov marked this pull request as ready for review July 28, 2026 04:01
@ijoukov
ijoukov requested a review from a team as a code owner July 28, 2026 04:01
Buzz edit events replace both message content and attachment metadata. Resolve the original message plus its latest kind 40003 edit so repeated CLI edits preserve the effective attachment state instead of resurrecting an older set.

Carry forward the complete imeta set and the trailing Markdown references required for rendering. Preserve existing file labels and spoiler formatting, synthesize missing references when metadata and content have drifted, avoid duplicates, and retain --clear-attachments as the explicit destructive path.

Add an SDK edit-builder variant for full attachment sets and regression coverage for preservation, clearing, replacement, deduplication, and the signed HTTP command payload.

Fixes block#3022

Signed-off-by: Ivan Joukov <1191567+ijoukov@users.noreply.github.com>
@ijoukov
ijoukov force-pushed the agent/preserve-cli-edit-attachments branch from a4580ac to cde4b47 Compare August 2, 2026 02:38
@ijoukov ijoukov changed the title fix(cli): preserve attachments when editing messages fix(cli): preserve attachments when editing messages (issue 3022) Aug 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

buzz messages edit silently deletes the message's attachments

1 participant