Spaces: creating a folder at the space root fails with "Create failed:" (empty error)

Cordy commented

2026-08-13 13:22:26 +00:00

Owner

Found dogfooding the openbao-custody instance (keyCustody openbao, postQuantum).

Repro:

In a Space, create a new folder at the space root → toast reads Create failed: with nothing after the colon (empty error).
Works everywhere else: creating a folder in Personal succeeds; creating folders and uploading files inside an already-existing space subfolder both succeed.

So the failure is specific to creating a folder at the top level of a space.

Two problems likely stacked:

Backend — the create-directory operation at a space root returns an error. Needs diagnosis: scope/path handling for the space root, or space-key provisioning on mkdir (note the space key already exists from a prior file upload, and file writes into the space work, so it is specifically the folder-create-at-root path).
Frontend — the error is not surfaced (Create failed: with an empty body). Likely the api() raw-Response pattern where the caller doesn't await res.json() on the error branch — same class as #136. Even once the backend is fixed, the empty-error display should be fixed so the next failure is diagnosable.

Possibly related to #174 (spaces create Conflict/invisible). First step: read the pod log for the failed create request's status + error, then the mkdir handler + space scope path, then the frontend create-folder error display.

Found dogfooding the openbao-custody instance (keyCustody `openbao`, postQuantum). **Repro:** - In a Space, create a new folder at the space root → toast reads **`Create failed:`** with nothing after the colon (empty error). - Works everywhere else: creating a folder in **Personal** succeeds; creating folders and uploading files **inside an already-existing space subfolder** both succeed. So the failure is specific to creating a folder at the **top level of a space**. **Two problems likely stacked:** 1. **Backend** — the create-directory operation at a space root returns an error. Needs diagnosis: scope/path handling for the space root, or space-key provisioning on `mkdir` (note the space key already exists from a prior file upload, and file writes into the space work, so it is specifically the folder-create-at-root path). 2. **Frontend** — the error is not surfaced (`Create failed:` with an empty body). Likely the `api()` raw-`Response` pattern where the caller doesn't `await res.json()` on the error branch — same class as #136. Even once the backend is fixed, the empty-error display should be fixed so the next failure is diagnosable. Possibly related to #174 (spaces create Conflict/invisible). First step: read the pod log for the failed create request's status + error, then the mkdir handler + space scope path, then the frontend create-folder error display.

Cordy added this to the v0.7 — Closed beta (dogfood + hardening) milestone

2026-08-13 13:22:26 +00:00

Cordy commented

2026-08-13 13:30:55 +00:00

Author

Owner

Diagnosis so far.

Folder-create uses POST /api/v1/dirs → h.Store.Mkdir (always wired; unrelated to the spaces-management API in #210). Through the scope driver (scope.go), Mkdir at a space root resolves cleanly for a member of the group, runs ensureReal, then inner.Mkdir("/spaces/<group>/<name>"). The only structural difference from the working cases — a folder in /home, or a folder deeper inside an existing space subfolder — is the encryption identity: a space key vs the user key.

Since file writes into the space and folder-create deeper inside the space both succeed, the space key itself is fine — so the failure is specific to Mkdir at the top level of a space. The empty Create failed: toast is a separate frontend bug: the api() raw-Response isn't parsed on the error branch, so no message surfaces (#136 class), which is why the real cause is invisible from the UI.

To pin the backend error I need the exact server response — the pod-log window didn't capture the failing request. Next step: reproduce the folder-create at a space root while tailing the cairn-openbao pod, read the status + writeErr body, then trace whether it's the encrypt layer's space-key handling on a dir marker at the space root or a scope/inner Mkdir edge.

**Diagnosis so far.** Folder-create uses `POST /api/v1/dirs` → `h.Store.Mkdir` (always wired; unrelated to the spaces-management API in #210). Through the scope driver (scope.go), Mkdir at a space root resolves cleanly for a member of the group, runs `ensureReal`, then `inner.Mkdir("/spaces/<group>/<name>")`. The only structural difference from the **working** cases — a folder in `/home`, or a folder deeper inside an existing space subfolder — is the encryption identity: a **space key** vs the user key. Since file writes into the space *and* folder-create deeper inside the space both succeed, the space key itself is fine — so the failure is specific to Mkdir at the **top level of a space**. The empty `Create failed:` toast is a separate frontend bug: the `api()` raw-`Response` isn't parsed on the error branch, so no message surfaces (#136 class), which is why the real cause is invisible from the UI. To pin the backend error I need the exact server response — the pod-log window didn't capture the failing request. Next step: reproduce the folder-create at a space root while tailing the `cairn-openbao` pod, read the status + `writeErr` body, then trace whether it's the encrypt layer's space-key handling on a dir marker at the space root or a scope/inner Mkdir edge.

Cordy commented

2026-08-13 14:50:17 +00:00

Author

Owner

Reproduced in-browser — and it is NOT a Mkdir bug. Corrected diagnosis:

Creating a folder at a real space root works: POST /api/v1/dirs → 201 (verified in the pod log — made debug-rootfolder inside Fall 3 with no error).
The Create failed: happens on the "New folder" button at the top-level Spaces list. That button doesn't call /dirs — it calls POST /api/v1/spaces (create a new space), which returns 404 (19-byte 404 page not found) — the exact same unwired-h.Spaces cause as #210.

So #209 and #210 are one backend issue (the spaces-management API isn't registered on this instance because no Keycloak admin client is configured), surfaced through two different buttons, plus the frontend swallowing the 404.

Reframed, the real defects are:

Create-space and member-management are unavailable on this instance, but the UI shows the controls anyway (the Spaces-root "New folder" button, the "Members" button) — they should feature-detect (like the audit panel #173) and hide/disable, or clearly say "spaces management isn't available here."
The frontend reports empty errors (Create failed: with no message; add-member silently nothing) — it must surface the real response, #136 class.

Folder creation within a space is fine and needs no change.

**Reproduced in-browser — and it is NOT a Mkdir bug.** Corrected diagnosis: - Creating a folder at a real space root **works**: `POST /api/v1/dirs` → `201` (verified in the pod log — made `debug-rootfolder` inside `Fall 3` with no error). - The `Create failed:` happens on the **"New folder" button at the top-level Spaces list**. That button doesn't call `/dirs` — it calls **`POST /api/v1/spaces`** (create a new space), which returns **`404` (19-byte `404 page not found`)** — the *exact same* unwired-`h.Spaces` cause as #210. So **#209 and #210 are one backend issue** (the spaces-management API isn't registered on this instance because no Keycloak admin client is configured), surfaced through two different buttons, plus the frontend swallowing the 404. Reframed, the real defects are: 1. **Create-space and member-management are unavailable on this instance, but the UI shows the controls anyway** (the Spaces-root "New folder" button, the "Members" button) — they should feature-detect (like the audit panel #173) and hide/disable, or clearly say "spaces management isn't available here." 2. **The frontend reports empty errors** (`Create failed:` with no message; add-member silently nothing) — it must surface the real response, `#136` class. Folder creation *within* a space is fine and needs no change.

Cordy referenced this issue

2026-08-13 14:50:20 +00:00

Spaces: "Add member" gives no feedback; needs a member picker (autocomplete + validation) #210

Cordy referenced this issue

2026-08-13 15:16:46 +00:00

Epic: spaces membership v2 — app-owned model (default) + IdP-write as optional power mode #211

Cordy referenced this issue

2026-08-13 15:17:37 +00:00

API + frontend: capability feature-detect for spaces; controls reflect availability; surface real errors #216

Cordy referenced this issue

2026-08-13 17:17:06 +00:00

Epic: spaces membership v2 — app-owned model (default) + IdP-write as optional power mode #211

Cordy commented

2026-08-13 22:49:28 +00:00

Author

Owner

Fixed and verified live. Root cause was exactly the stacked pair called out here: the create-space POST at a Space root 404'd because spaces management was only wired when a Keycloak admin client was configured (openbao custody has none), and the frontend swallowed the error (api() raw Response never .json()'d on the failure branch → empty Create failed:).

Resolved by the #211 epic rather than a point patch:

app-owned space store in the encrypted state-backend (#213) + scope integration (#214) — a Space root create no longer needs any IdP write;
capability feature-detect + real error surfacing (#216) — controls reflect availability and failing calls show the server message.

Verified on v0.6.18, both deployment types:

cairn-openbao (openbao custody, app-owned path): "New folder" at the Spaces root creates a space (POST 201); the created space app-owned-space persisted across a redeploy.
cairn-enc (keycloak-profile, IdP-managed power mode — boot log IdP-managed spaces enabled (power mode)): create-space + members controls present and working.

Empty-error class closed too: failures now surface the real message on both paths. Closing.

Fixed and verified live. Root cause was exactly the stacked pair called out here: the create-space POST at a Space root 404'd because spaces management was only wired when a Keycloak **admin** client was configured (openbao custody has none), and the frontend swallowed the error (`api()` raw `Response` never `.json()`'d on the failure branch → empty `Create failed:`). Resolved by the #211 epic rather than a point patch: - app-owned space store in the encrypted state-backend (#213) + scope integration (#214) — a Space root create no longer needs any IdP write; - capability feature-detect + real error surfacing (#216) — controls reflect availability and failing calls show the server message. **Verified on v0.6.18, both deployment types:** - **cairn-openbao** (openbao custody, app-owned path): "New folder" at the Spaces root creates a space (POST 201); the created space `app-owned-space` persisted across a redeploy. - **cairn-enc** (keycloak-profile, IdP-managed power mode — boot log `IdP-managed spaces enabled (power mode)`): create-space + members controls present and working. Empty-error class closed too: failures now surface the real message on both paths. Closing.

Cordy closed this issue

2026-08-13 22:49:32 +00:00

Cordy referenced this issue

2026-08-13 22:49:44 +00:00

Epic: spaces membership v2 — app-owned model (default) + IdP-write as optional power mode #211

Rows
Columns

Spaces: creating a folder at the space root fails with "Create failed:" (empty error) #209