Store attachments through the dedup pipeline instead of one object per upload

FixMediaService
Ya
6 Agosti 2026, 20:45 UTC
Mwandishi
Kamo
Ahadi ya
0eda67f

Attachments wrote their own "<imgId>/<fileName>" object on every upload, bypassing the content-addressed store entirely — the same logo-draft.png attached three times in one conversation occupied three objects. Uploads now hash into a shared ImgDat, so identical content is stored once no matter how often it is attached, and an attachment that matches a document already in the system costs no storage at all. The Img row stays per-attachment: it carries the conversation, uploader and revocation state, and it is still what access is checked against. Only the bytes are shared. Reads resolve the content-addressed key when the row has a dat and fall back to the legacy per-upload object when it does not, so attachments predating this keep working — including any written by an instance that has not rolled over yet. ChatAttachmentDedupBackfill folds those legacy attachments in on startup: it selects only rows with a null dat and sets that dat last, so it is idempotent, self-healing across the rollout, and a failure on one row leaves it on the still-working legacy path rather than failing startup. Legacy objects are left in place; nothing deletes from MinIO.

Mabadiliko yote

Je, unaona nini kuhusu usafiri?

Kila moja ya hizi updates ardhi katika nafasi yako ya kazi moja kwa moja. Kuanza bure na kuangalia kukua wiki baada ya wiki.

Kuwa Huru MileleMtazamo wa bei