Feature Summary
Deleting a workflow's notebook only removes the database rows. deleteNotebookAndMapping in NotebookMigrationResource.scala deletes from the notebook table (cascading to workflow_notebook_mapping), but nothing removes the corresponding .ipynb file from the Jupyter pod's work/ directory.
This was self-limiting before per-workflow filenames: every workflow uploaded to the same work/notebook.ipynb, so there was only ever one file and it was overwritten on the next use. Now that each workflow uploads to work/notebook_<wid>.ipynb (#7671), these files accumulate one per workflow and survive a delete, so the pod's work/ directory grows unbounded and holds notebooks for workflows the user already deleted.
Proposed Solution or Design
On delete, remove the workflow's notebook file from Jupyter in addition to the database rows. The file name is derived from the workflow id the same way the upload derives it (notebook_<wid>.ipynb). A delete against the Jupyter Contents API (DELETE /api/contents/work/<name>) mirrors the existing upload path (PUT /api/contents/work/<name> in setNotebook).
Points to decide when this is picked up:
- Whether the frontend passes the notebook name on delete (as it now does on upload and iframe fetch) or the backend derives it from the wid.
- Whether a missing file on delete is treated as success (idempotent), consistent with how the DB delete already reports
deleted: 0 when nothing was stored.
- Whether to also sweep pre-existing orphaned files, or only fix the delete path going forward.
This is a follow-up to the per-workflow filename change (#7671) and does not block it.
Affected Area
Other
Feature Summary
Deleting a workflow's notebook only removes the database rows.
deleteNotebookAndMappinginNotebookMigrationResource.scaladeletes from thenotebooktable (cascading toworkflow_notebook_mapping), but nothing removes the corresponding.ipynbfile from the Jupyter pod'swork/directory.This was self-limiting before per-workflow filenames: every workflow uploaded to the same
work/notebook.ipynb, so there was only ever one file and it was overwritten on the next use. Now that each workflow uploads towork/notebook_<wid>.ipynb(#7671), these files accumulate one per workflow and survive a delete, so the pod'swork/directory grows unbounded and holds notebooks for workflows the user already deleted.Proposed Solution or Design
On delete, remove the workflow's notebook file from Jupyter in addition to the database rows. The file name is derived from the workflow id the same way the upload derives it (
notebook_<wid>.ipynb). A delete against the Jupyter Contents API (DELETE /api/contents/work/<name>) mirrors the existing upload path (PUT /api/contents/work/<name>insetNotebook).Points to decide when this is picked up:
deleted: 0when nothing was stored.This is a follow-up to the per-workflow filename change (#7671) and does not block it.
Affected Area
Other