mirror of
https://github.com/mattermost/mattermost.git
synced 2026-09-19 10:12:47 +08:00
Doug Lauder
5504435231
* MM-68705 - Make ReceiveSharedChannelAttachmentSyncMsg order tolerant
Allow plugin remotes to invoke ReceiveSharedChannelAttachmentSyncMsg
and ReceiveSharedChannelSyncMsg in either order without losing the
post/file binding, and make repeat deliveries of the same file id
idempotent.
Two localised changes inside ReceiveSharedChannelAttachmentSyncMsg:
- Idempotency check before CreateUploadSession. If a FileInfo with
the sender's id already exists for the same channel and creator,
return it instead of inserting a duplicate (which would violate
the FileInfo PK and force the caller to retry indefinitely after
any transient ack failure). A mismatched channel or creator on the
same id is rejected.
- Lazy bind to post after UploadData. When the matching post is
already present (post-then-file ordering), CreatePost will have
stripped the unmatched file id from Post.FileIds; AttachToPost
plus Post.Overwrite restore the binding. When the post is not
yet present (file-then-post ordering), the FileInfo is left
unbound so the eventual post arrival's CreatePost path binds it.
The post is fetched first because AttachToPost is a blind UPDATE
that does not validate post existence, so calling it before the
post exists would orphan the FileInfo.
No other paths change. Cluster (non-plugin) shared-channel attachments,
ReceiveSharedChannelProfileImageSyncMsg, and UI uploads are unaffected.
New tests in shared_channel_test.go cover both orderings, repeated
receive success and rejection on channel/creator mismatch, and the
empty-PostId no-op.