From 476abe07fc2c1587f4b3e3916134018ebacd143d Mon Sep 17 00:00:00 2001 From: Jamie Pine <32987599+jamiepine@users.noreply.github.com> Date: Fri, 17 Apr 2026 17:53:11 -0700 Subject: [PATCH] fix(paths): strip legacy "data/" prefix when resolving stored paths (#440) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 0.3.0 sometimes stored relative media paths with the data-dir name baked in (e.g. "data/profiles//sample.wav"). resolve_storage_path joined those directly with _data_dir, producing "/data/profiles/..." — a spurious double nest that breaks file reads after upgrading to 0.4.0. The 0.4.0 startup migration didn't catch it because resolve_storage_path produced the buggy double-nested path, to_storage_path saw "data" at the first (legitimate) index, and the normalized value matched the stored value so the row was skipped. Strip any leading "data/" component before joining. This unblocks runtime reads and lets _normalize_storage_paths rewrite the affected rows on next startup — no manual migration needed. Fixes "No such file or directory: '/data/profiles/...'" and associated 404s on GET /audio/ after upgrading from 0.3.0 to 0.4.0. Co-authored-by: Claude Opus 4.6 (1M context) --- backend/config.py | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/backend/config.py b/backend/config.py index 959731c6..0cbce59d 100644 --- a/backend/config.py +++ b/backend/config.py @@ -89,6 +89,14 @@ def resolve_storage_path(path: str | Path | None) -> Path | None: return stored_path + # 0.3.0 records sometimes stored relative paths with the data-dir name + # baked in (e.g. "data/profiles/..."). Joining those directly with + # _data_dir produces a spurious "/data/profiles/..." nest. + if stored_path.parts and stored_path.parts[0] == "data": + stored_path = ( + Path(*stored_path.parts[1:]) if len(stored_path.parts) > 1 else Path() + ) + return (_data_dir / stored_path).resolve()