From 4727bad5ebd37cf2344416ae937b02a931113ec3 Mon Sep 17 00:00:00 2001 From: David Heinemeier Hansson Date: Tue, 11 Aug 2026 14:16:32 -0700 Subject: [PATCH] Stop the update-lock stub racing the holder it spawns The stub polled for the lock with its own flock, competing with the holder it had just started. The holder took the lock non-blockingly and never retried, so a lost race killed it and left the lock free. The notifier then saw no update in progress and sent the toast the test asserts it withholds. Wait on the holder's own signal instead. Co-Authored-By: Claude Opus 5 --- test/shell.d/migrate-notify-test.sh | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/test/shell.d/migrate-notify-test.sh b/test/shell.d/migrate-notify-test.sh index 84dc7be3..8114e6d9 100644 --- a/test/shell.d/migrate-notify-test.sh +++ b/test/shell.d/migrate-notify-test.sh @@ -31,15 +31,21 @@ cat >"$stub_bin/omarchy-notification-wait" <<'SH' [[ ${OMARCHY_TEST_LOCK_DURING_WAIT:-0} == 1 ]] || exit 0 lock="$XDG_RUNTIME_DIR/omarchy-update.lock" +held="$lock.held" +rm -f "$held" : >"$lock" # Hold the lock through a bash-allocated descriptor rather than `flock # `: bash marks those close-on-exec, so the holder owns the lock alone -# and killing it releases immediately, with no exec'd child to outlive it. -bash -c 'exec {fd}>"$1"; flock -n $fd || exit 1; sleep 60' _ "$lock" & +# and killing it releases immediately, with no exec'd child to outlive it. The +# holder blocks for the lock instead of taking it non-blockingly, so it cannot +# lose a startup race and leave the lock unheld. +bash -c 'exec {fd}>"$1"; flock $fd || exit 1; : >"$2"; sleep 60' _ "$lock" "$held" & echo "$!" >"$OMARCHY_TEST_LOCK_HOLDER_PID" +# Wait on the holder's own signal rather than probing with flock. Probing would +# contend for the very lock we are waiting to see taken. for _ in {1..200}; do - flock -n "$lock" true 2>/dev/null || exit 0 + [[ -e $held ]] && exit 0 sleep 0.05 done