Files
sencho/backend
Anso 4be3319a07 fix: surface NOT_EMPTY error code so DeleteFileConfirm can offer recursive delete (#1765)
* fix: surface NOT_EMPTY error code so DeleteFileConfirm can offer recursive retry

The parseApiError helper discards the backend's machine-readable code field,
returning only the human-readable message. DeleteFileConfirm tried to detect
non-empty directory refusals by matching the substring NOT_EMPTY against the
message text, but the actual server message is "Directory is not empty" (with
spaces, not underscores), so the two-step "Delete all" confirmation flow was
dead code.

Add a NotEmptyError class (mirroring the existing UploadConflictError pattern)
and intercept HTTP 409 responses in deleteStackPath so the code is preserved.
Replace the fragile string match in DeleteFileConfirm with instanceof.

* fix: extend NOT_EMPTY fix to volume roots and fix stale viewer after recursive delete

P0-1: sendFsError's helper/ExecError branch (volume-browser deletes) never
attached a code field to 409 responses, so the frontend NotEmptyError was
never thrown for named-volume non-empty directories. Map ExecError 409s
whose message matches 'not empty' to code: NOT_EMPTY.

P0-2: The context-menu delete onDeleted callback used an exact-match check
(ctxDeletePath === selectedPath) to decide whether to clear the viewer.
When deleting a folder containing the open file, the viewer stayed open
showing now-deleted content. Use the existing openFileAffectedBy helper
(which checks ancestor paths) instead, matching bulk-delete behavior.
2026-08-04 01:37:55 -04:00
..