fix(browse): treat 404 on directory fetch as empty, not an error

Expanding a folder that returns 404 used to throw "HTTP 404 fetching
…" through statusError, surfacing it as a red error toast. From the
user's POV, a missing or empty directory shouldn't be presented as a
load failure — empty IS the legitimate state.

fetchServerChildren now returns [] on 404; other non-2xx still throw.
Other failure modes (transport error, 500, malformed JSON) continue
to surface as before.

Server-side, zddc-server already returns 200 + [] for canonical
project folders that don't exist on disk (the prior commit). This
client fix covers the residual cases:
  - non-canonical paths that don't exist (deleted between listing
    and expand; race with concurrent writers)
  - non-zddc-server backends (Caddy file_server, plain nginx) where
    we can't change the 404 behavior

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
ZDDC 2026-05-09 20:34:53 -05:00
parent 3fc371752a
commit 76e8dab009

View file

@ -62,12 +62,24 @@
// Fetch children of a directory in server mode.
// path must end with '/' so the request hits the directory route.
//
// 404 is treated as "empty directory" rather than a hard error.
// A directory that doesn't exist on the server (e.g. a fresh
// project's working/ before any drafts have been created, or a
// dir deleted between listing and expand) is functionally
// indistinguishable from an empty one for tree-rendering purposes.
// Server-side, zddc-server already returns 200 + [] for canonical
// project folders that are missing on disk; this fallback covers
// the same UX for anything else and for non-zddc-server backends.
async function fetchServerChildren(path) {
if (!path.endsWith('/')) path += '/';
var resp = await fetch(path, {
headers: { 'Accept': 'application/json' },
credentials: 'same-origin'
});
if (resp.status === 404) {
return [];
}
if (!resp.ok) {
throw new Error('HTTP ' + resp.status + ' fetching ' + path);
}