Library Trash (phase 4a of 01-sources-and-folders): taking it, if it is free

Aperta
  • Qualcosa non va?
#2,375 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
30/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python
Ambito
backend, database, full-stack

Direzione di ricerca

Read the Trash section of docs/proposals/file-agent/01-sources-and-folders.md and the Known gaps entry in docs/architecture/documents.md first. The issue names modules/folders/trash.py, folders/delete_folder.py, and the related routes and tests as starting points; confirm the proposal details with maintainers before taking this cross-cutting work. Done means the agreed Trash behavior is implemented across backend and frontend, with the listed tests passing and the architecture document updated.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Taking it, if it is free: the Library Trash, phase 4a of 01-sources-and-folders.md. It is the first line of Known gaps in docs/architecture/documents.md: "Deleting a folder is permanent; the Trash is designed, not built."

What is on dev (36c42457b)

  • 0025_source_roots_and_folders already has folders.state with trashed and deleting, plus trash_kind and trashed_at.
  • source_scope/resolve.py and the agent's thread_folder/mirror_path.py already leave out trashed and deleting subtrees.
  • The tree's delete still goes to DELETE /folders/{id} (folders/delete_folder.py) and DELETE /documents/{id}, both permanent.
  • There is no trash.py, purge.py, /trash route or blob_tombstones yet.

Plan. Three PRs against dev, each built to the proposal as written:

  1. Move to Trash and Restore (modules/folders/trash.py, POST /trash, GET /trash, POST /trash/{folder_id}/restore):
    • A folder is marked trashed in place.
    • Loose documents go into one "Deleted {date} {time}" wrapper per source folder.
    • The subtree's pending and processing rows are cancelled in the same transaction.
    • Filed artifacts pass versions.guard_delete first.
    • Restore handles the " (restored)" rename and the re-queue at PRIORITY_BULK.
    • FOLDERS events carry the ids.
  2. Purge (purge.py, DELETE /trash/{folder_id}, DELETE /trash):
    • Every subtree is set to deleting first. Documents are then removed in batches of up to 500, each in its own transaction, then folders deepest first.
    • A blob_tombstones table (a new plain migration) gets a row for each documents/<id>/ and artifacts/<id>/ directory as it is removed.
    • orphan_directories.py::sweep_tombstones runs at start.
    • An hourly lifespan task purges entries older than 30 days.
  3. Frontend:
    • The Trash row at the end of the Library, with counts, size and purge date. Each entry has Restore and Delete now, plus Empty Trash.
    • The tree's delete moves rows to the Trash with an Undo toast. DELETE /documents/{id} keeps its permanent meaning for plugins.
    • This PR moves the Trash part of the design into docs/architecture/documents.md and removes the Known gaps line.

Each backend PR comes with tests for its steps from the proposal: scope exclusion at once, restore intact, a cancelled job no-oping at begin_job, batch size, deepest-first order, and a tombstone kept when a directory cannot be removed. Linked roots (4b) are out of scope.

Two questions before I start

  • Is anyone already on this, or is it planned on your side?
  • The proposal's status is in-progress. Do you want anything changed in the Trash section first, such as the 30-day estimate or the "Deleted {date} {time}" wrapper name, or should I build it as written?
Lingua principale
Python
Stelle
16.3k
Fork
1.6k
Merge medio
18h 52m
PR unite (30g)
218

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di MODSetter/SurfSense

Tutte le issue di MODSetter/SurfSense

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.