conf: publish_replica() os.replace breaks symlinked replica paths (worktree leaf-symlink pattern) #619
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: homelab/stack#619
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Found during P37 #612:
conf/connect.pypublish_replica()usesos.replace(tmp, dst), which replaces the symlink itself rather than following it — in a git worktree using the documented leaf-symlink pattern (data/aco.ro.duckdb→ main checkout), the publish silently detaches the symlink into a stale standalone copy while the real shared replica (and the DuckLake publish that reads it via the notebooks container) stays out of date. Fix: resolvedstwithPath(dst).resolve()before the tmp-write/replace dance (atomic-replace next to the RESOLVED target). Workaround applied manually in P37 Task 6 (re-published + restored symlink).Fixed in e91ea1c: src/conf/connect.py:155 now resolves the replica path before the tmp-write/
os.replacedance, so a symlinked<name>.ro.duckdb(worktree leaf-symlink pattern) has its shared target atomically refreshed instead of the symlink being replaced by a detached stale copy.Substantiation: TDD — the new regression test tests/conf/test_connect.py:338 (
test_publish_follows_symlinked_replica) reproduced the exact failure first (publish detached the symlink into a standalone copy), then went green with the one-line fix; fulltests/conf/test_connect.pysuite 29/29 passed and the pre-commit hook gate was green on commit. Resolving to the target also keeps the atomicity guarantee: the tmp file now lands next to the resolved destination, same filesystem.