You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit a53aadc
Browse filesBrowse the repository at this point in the historyBrowse files
fix(cleanup): keep chat files another chat of their scope still references
A fork names its source's storage key wherever it did not copy the file: an
organization attachment, a message-only copilot attachment, or an upload whose
blob copy failed (`publishedFileRefMaps` leaves those keys in the fork's
messages). The fork comment said cleanup deletes a shared key only once no
chat references it, but the reference check covered `assistant/<org>/` keys
alone, so deleting the source chat deleted the upload a fork still showed.
Every collected key now carries the scope whose chats may still reference it
(`organizationId`, or `workspaceId` from its `workspace_files` row, else the
chat's), and `deletableChatFiles` runs the existing batched `@>` containment
over that scope's messages for every key before the handler or the retention
path deletes it. A chat with no workspace or organization records
`workspaceId: null`: no fork can be made from it. The payload field is
optional, so events already queued still parse; for those, the scope is
recovered from the key where it names one (`assistant/<org>/`,
`workspace/<id>/`), a chat's own inline images need no check, and any other
key is kept and logged rather than risk deleting a file a fork shows. The
fork's `for('key share')` on the source row still orders the two: the check
runs only after the source row is gone, and the fork lives in the same scope.
Autopsy: the only shared-key test used an organization attachment, the one
kind the check covered; no test forked a workspace chat whose upload copy
failed, so the unchecked mothership and copilot keys went unnoticed. The new
integration case deletes a source chat whose upload a fork still references,
and fails on the old handler with the object gone; a second case pins how
events queued before this change are handled.
0 commit comments