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 9e9fac3
Browse filesBrowse the repository at this point in the historyBrowse files
fix(cleanup): purge chat inline images by prefix instead of by transcript
Inline chat images live at `chat-images/<chatId>/<requestId>/<sha>.webp`
with no `workspace_files` row, and chat cleanup found them by re-deriving
keys from the transcript it read before the delete. An image a turn published
after that read, which the admin removal hook and the account deletion
pre-read both leave a window for, was never collected and stayed in storage.
The `copilot.chat.backend-cleanup` handler now deletes every object under
`chat-images/<chatId>/` for each chat it confirms deleted, through the same
paged listing and deadline-aware step the Project prefix cleanup uses (moved
into `lib/uploads/core/sweep-prefix.ts` and shared), checkpointing how many
chats it finished and continuing in a later run near its deadline.
`collectChatFiles` no longer derives inline image keys and reads only each
message's `fileAttachments`.
So that every path still reaches the sweep, chat ids are queued even without
`COPILOT_API_KEY`, with a `copilotBackend` flag saying whether they also go to
the backend (absent on already-queued events, which keeps their meaning), and
the retention jobs behind `prepareChatCleanup` queue an image-only event for
the chats they confirm deleted. Events already queued with inline image file
entries still delete those keys normally. Comments on the account deletion
and admin removal paths now state the residual precisely: chats created after
the read, and attachments added to an already-read chat.
Autopsy: the tests seeded each chat's images together with the transcript
that names them, so collecting keys from the transcript always matched what
was stored; none wrote an object after the cleanup read, which is the window
the two removal paths leave open. The new integration case writes images
after the admin hook's read and fails on the old handler with the late images
still on disk; a bystander chat's images stay untouched.
0 commit comments