fix: harden release status checks

[flamerged]

Summary

• reject literal latest when parsing release asset URLs as fallback tags
• acquire release-check locks atomically before spawning background refreshes

Validation

• ./scripts/check.sh
• latest fallback smoke
• active lock smoke
• release check success smoke
• cr --type uncommitted

Summary by CodeRabbit

• Bug Fixes
  • Improved release tag validation to reject invalid tag values and avoid unintended fallback behavior.
  • Strengthened release-check cache locking to better detect and remove stale locks, reducing race conditions and improving reliability during concurrent operations.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 2432fcdd-82c8-4e88-9c83-a2ff9f815744

📥 Commits

Reviewing files that changed from the base of the PR and between f583215 and e6d1968.

📒 Files selected for processing (1)

• bin/menutube.5s.sh

🚧 Files skipped from review as they are similar to previous changes (1)

• bin/menutube.5s.sh

---

📝 Walkthrough

Walkthrough

Rejects the literal tag "latest" when deriving a release tag from asset URLs and rewrites lock acquisition in the release-check refresh: compute lock age, remove stale locks (with re-check), and create the lock with noclobber, returning early on contention.

Changes

Release-Check Robustness

Layer / File(s)	Summary
Tag validation and lock-file hardening bin/menutube.5s.sh	latest_release_tag_from_asset_url treats the extracted tag as invalid if it is empty or equals latest. maybe_refresh_release_check computes lock mtime/age, removes stale locks after re-checking mtime, and attempts lock creation with set -C (noclobber); failure to create the lock causes an early return.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

• flamerged/menutube#3: Introduces the release-check helpers (latest_release_tag_from_asset_url and maybe_refresh_release_check) that this PR refines.

Poem

🐰 In shell I nibble bugs away,
I banish latest from the play.
Locks grow stale—I toss the key,
Noclobber sets the races free.
Hop, menutube—safe and gay! 🎬

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'fix: harden release status checks' directly relates to the main changes: rejecting invalid 'latest' tags and hardening release-check lock acquisition with atomic/stale-lock handling.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/release-check-hardening

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@bin/menutube.5s.sh`:
- Around line 332-333: The current stale-lock cleanup uses a previously computed
lock_age and unconditionally removes "${MENUTUBE_RELEASE_CHECK_CACHE}.lock",
which can delete a lock another process just created; change the logic so you
re-check the lock's age immediately before removal and only unlink if the
on-disk lock is still older than your stale threshold: after the atomic create
attempt (the ( set -C; : > "${MENUTUBE_RELEASE_CHECK_CACHE}.lock" ) ...), if
creation failed, inspect the lock file's current modification time (e.g. via
stat -c %Y or find -mmin) and compute its age relative to now (use the same
stale threshold as lock_age) and only rm -f
"${MENUTUBE_RELEASE_CHECK_CACHE}.lock" if that fresh check proves it is stale;
this ensures you won't remove a lock that another process just acquired.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: d0329dfa-1c8c-4f34-8006-e7ec153f2a97

📥 Commits

Reviewing files that changed from the base of the PR and between df3c106 and f583215.

📒 Files selected for processing (1)

• bin/menutube.5s.sh