bug: workspace display name silently reset to the path basename by routine autosaves

[penradioGables]

Summary

Renaming a workspace does not stick. The name reverts to the raw path basename (cptr for /home/cptr) shortly afterwards, at what looks to the user like a random moment — it is actually the next routine autosave.

Verified still present in v0.9.15 — cptr/routers/state.py is byte-identical between the v0.9.10 and v0.9.15 tags.

Root cause

routers/state.py::put_workspace (PUT /api/state/workspace, L169–180) defaults name to the path basename whenever the request body omits the key:

    name = workspace_data.pop("name", _workspace_display_name(workspace_path))
    workspace_data.pop("path", None)
    # Everything else is workspace data (groups, tabs, etc.)
    await Workspace.upsert(user_id, workspace_path, name, workspace_data)

Routine tab/layout/group autosaves from the frontend never include "name". .pop(key, default) cannot distinguish "the caller omitted this" from "the caller set this", so every such autosave overwrites the stored name with the basename.

Note the read path already does the right thing — workspace.name or _workspace_display_name(path) (L98) — so the fallback exists in both places, and only the write path needs to stop applying it unconditionally.

Why it matters beyond cosmetics

The model id exposed to OpenAI-compatible clients is derived from the workspace, so this churns the advertised model identity too. With two cptr instances attached to the same Open WebUI, both collapse to the same basename-derived id and collide. (Working around that at the OWUI end with a connection prefix_id is what made the underlying reset visible to us in the first place.)

Suggested fix

Only fall back to the basename when no row exists yet; when a row exists and the request omits name, preserve the stored value.

Happy to open a PR.

[tjbck]

Should be addressed!