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 6de1f2f
Browse filesBrowse the repository at this point in the historyBrowse files
fix(account-deletion): durably purge a deleted workspace's storage by prefix
Account deletion found the objects to erase by reading their rows before the
teardown transaction and deleting them in memory after commit. Anything that
read could not see stayed in storage forever: rows written between the read
and the workspace lock, rowless objects (table snapshots, compiled documents,
table-import leftovers, execution objects whose metadata insert failed),
everything past the 100k in-memory cap, everything after a crash following
commit, and the account's private files in workspaces that survive it, whose
rows cascade away with the user.
Inside the deletion transaction, after the workspace rows are locked, account
deletion now queues delayed outbox work that commits or rolls back with it:
- one prefix sweep per deleted workspace across workspace/, table-import/,
execution/, table-snapshots/, copilot-doc-compiled/ and workspace-logos/
in the bucket serving each, with a trailing-slash prefix built from a
validated id;
- exact-key cleanup for what cascades outside those prefixes: knowledge-base
documents, Copilot uploads and other non-prefixed files of deleted
workspaces, and the account's private files elsewhere (attachments of its
own chats, private contexts, files with no workspace). Handed-off, Project,
organization files and attachments of someone else's chat are not queued.
Both wait out every upload URL signed before the deletion, refuse as a no-op
when the workspace or account row exists again (restore, PITR), and keep any
key a surviving workspace_files, workspace_file, workspace_file_version,
document or execution_large_values row still references. The sweep reuses the
Project prefix cleanup's provider listing and deletion, generalized by storage
context and given an in-run provider cursor; Project cleanup still lists one
page per run and deletes exactly as before. The existing in-memory purge is
unchanged and still runs.
Large execution values now pass cleanupOnMetadataFailure, so a failed
metadata insert deletes the freshly keyed object instead of orphaning it, as
execution files already do.
0 commit comments