Skip to content

fix(imap): keep APPENDUID stable and apply labels on APPEND - #113

Merged
findleyl merged 3 commits into
mainfrom
fix/imap-append-uid-stability
Oct 12, 2026
Merged

findleyl merged 3 commits into
mainfrom
fix/imap-append-uid-stability

Conversation

@findleyl

Copy link
Copy Markdown
Member

What changes

  • The UID returned by APPENDUID stays the same after a sync pass. A pass that listed a folder before the APPEND finished no longer moves or prunes the new message.
  • APPEND sends the target mailbox with the import request. When a message cannot be filed in Archive, Trash, or Junk, the command answers NO and leaves no copy.
  • Keywords in the APPEND flag list are applied as labels, with the same reserved names and ten-new-labels cap as STORE.
  • A repeated APPEND of a message that is already in the target mailbox returns its APPENDUID, and its label keywords are added to the existing copy.

Testing

The aster-bridge-core suite covers each case, including the stale-listing race and the heal retry.

A sync pass that listed a folder before an APPEND finished could act on
that stale view afterwards: an inbox page moved the new message out of
its mailbox and dropped its UID, and a deep pass pruned it as deleted.
Either way the message came back under the next UID while UIDVALIDITY
stayed the same, and old mail could stay filed in the inbox.

- Remember each appended message and skip sync writes and prunes that
  were decided from a listing older than the append.
- Send the placement with the import request, retry the follow-up
  update, and answer NO without leaving a copy when a message cannot be
  filed in Archive, Trash or Junk.
- Apply keywords from the APPEND flag list as labels, with the same
  reserved names and ten-new-labels cap as STORE. A failed label write
  is reported as an untagged NO ahead of the tagged OK, because the
  message is stored.
- Answer a repeated APPEND with the APPENDUID of the message already in
  that mailbox.
A deduplicated APPEND now adds its label keywords to the copy already cached, in any mailbox, and warns with an untagged NO when a label write fails. APPENDUID is still returned only when the copy is in the target mailbox. The inbound heal retry now honors the append record, so a listing taken before an APPEND cannot refile the message.
@findleyl
findleyl merged commit ae94c01 into main Oct 12, 2026
12 checks passed
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.

1 participant