T-PKMM-single-note-restore-keeps-suffixed-trash-name
State: planning/draft · Impact: medium · Complexity: small
Deleting a single note into an already-occupied trash slot suffixes the
trashed file’s name (foo 1.md) to avoid a collision. Restoring it
brings it back under that suffixed name, not its real original name,
because the trash path is the only record of where the note came from.
Bundle deletes got a real fix for the same class of bug; this is the
single-note half, left open on purpose.
| Location | Role today |
|---|---|
solutions/determined/crates/determined-notes/src/content.rs:926 | delete_doc’s free_path(vault_dir, "{TRASH_DIR}/{normalized}") silently suffixes the destination name on a collision; nothing records the pre-suffix name anywhere but the returned trashed_to string itself |
solutions/determined/crates/determined-notes/src/content.rs:1073-1084 | restore_doc strips the .trash/ prefix from the trashed path verbatim and restores there — if that path was suffixed, the note comes back suffixed too |
solutions/determined/crates/determined-notes/src/content.rs:567 | write_frontmatter_fields, the existing general-purpose frontmatter writer this task can reuse to stamp and clear an origin key |
Proposed
Section titled “Proposed”A note trashed under a collision-suffixed name restores to its real
original path, not the suffixed one. The origin path is recorded
somewhere durable enough to survive being the only trace once the note
is in .trash/.
Approach
Section titled “Approach”- When
free_pathindelete_dochas to suffix the destination (i.e. the naive.trash/{normalized}path was taken), stamp the moved file’s frontmatter with the real original relative path viawrite_frontmatter_fields, keyed distinctly from user-facing fields (e.g.ap-trashed-from). - In
restore_doc, prefer that stamped key as the restore destination when present, falling back to today’s strip-prefix behavior when absent (an unsuffixed trash entry, or one trashed before this fix). - Strip the stamped key from the note’s frontmatter as part of the restore write, so a restored note carries no trash bookkeeping.
- Add regression tests: delete twice into the same slot (forcing a suffix), restore the second, assert it lands at its real original path, not the suffixed one.
| Area | Note |
|---|---|
solutions/determined/crates/determined-notes/src/content.rs | Stamp origin path on a suffixed trash write; read and strip it on restore |
Acceptance criteria
Section titled “Acceptance criteria”- AC-1: Trashing a second note into an occupied slot, then restoring it, returns it to its real original path, not the suffixed trash name.
- AC-2: An unsuffixed trash entry (no collision) restores exactly as it does today — no behavior change for the common case.
- AC-3: A restored note’s frontmatter carries no leftover trash bookkeeping key.
Out of scope
Section titled “Out of scope”- Bundle delete/restore — already fixed; this task is single-note only.
- A user-facing trash browser or manifest; the fix stays inside the note’s own frontmatter.
Dependencies
Section titled “Dependencies”- none
Discovery context
Section titled “Discovery context”Found by the agent-pants bug survey, N-5LD4-bug-sweep-2026-09-12-agent-pants, noted as a pre-existing, untouched gap alongside the bundle-restore fix for AP-106/AP-107/AP-108.