fix: use semver-based latest detection for releases - #6
Merged
Conversation
Set make_latest: "legacy" so GitHub determines the latest release based on semantic versioning rather than marking every new release as latest regardless of version order. https://claude.ai/code/session_01QBX4wtsg4wwyhcyZhG7GpS
dvcdsys
added a commit
that referenced
this pull request
May 12, 2026
…dule Previous backoff streak retried indefinitely with delay capped at 30m, which meant a permanent GitHub outage produced ~48 polls per day per server. Now a streak gives up after MaxBackoffAttempts (default 5) and the next attempt is anchored to streakStart + Interval — i.e. the regular 6h grid resumes from the FIRST attempt of the failed streak, not from "now". Worst case progression with defaults (Interval=6h, Initial=1m, Max=30m): attempt #1 fails T = 0 attempt #2 fails (wait ~1m) T = +1m attempt #3 fails (wait ~2m) T = +3m attempt #4 fails (wait ~4m) T = +7m attempt #5 fails (wait ~8m) T = +15m → exhaust attempt #6 fires T = T0 + 6h (anchor) Successful poll mid-streak resets attempt counter and wait reverts to Interval. The "anchor from first attempt" choice keeps the long-term schedule on its grid even when a streak ate up to ~30m of it; an absurdly long streak (rare; needs Interval < BackoffMax × N) collapses the wait to 0 and fires immediately, which is the only sensible behaviour when we already overshot. - MaxBackoffAttempts surfaced on Config (default 5). - TestRunStreakExhaustedAnchorsToInterval covers the exhaust path: 3 fails → anchored sleep → #4 fires near streakStart+Interval. - Existing TestRunBacksOffOnFailureThenResets unchanged (recovers after 2 fails, well below the cap). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
dvcdsys
added a commit
that referenced
this pull request
May 14, 2026
…projects Two related correctness fixes: 1. POST /git-repos was not transactional — a failed gitrepos insert (e.g. UNIQUE violation under concurrent posts) left an orphan projects row in 'pending' that the dashboard couldn't surface for cleanup. The handler now tracks whether it created the project row and runs a compensating DeleteByHash on gitrepos failure. TestAddGitRepo_ConcurrentDuplicate_NoOrphan asserts the invariant: SELECT COUNT(*) FROM projects WHERE host_path = ? == 1 after two parallel posts. 2. workspaceprojects.Link checked precondition + did INSERT in two separate queries — race window where the project could be deleted between the SELECT and INSERT surfaced as a 500 instead of 404. Rewritten as a single INSERT ... SELECT ... WHERE EXISTS, with a follow-up diagnostic SELECT when RowsAffected == 0 to return the right 404/422 reason. 3. TestDeleteProject_CascadesGitRepoAndMembership now explicitly asserts SELECT COUNT(*) FROM workspace_projects WHERE project_path = ? == 0 (instead of relying on UNIQUE-retry inference). Resolves Fix #5, #6, #15, #16. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
dvcdsys
added a commit
that referenced
this pull request
May 14, 2026
…projects Two related correctness fixes: 1. POST /git-repos was not transactional — a failed gitrepos insert (e.g. UNIQUE violation under concurrent posts) left an orphan projects row in 'pending' that the dashboard couldn't surface for cleanup. The handler now tracks whether it created the project row and runs a compensating DeleteByHash on gitrepos failure. TestAddGitRepo_ConcurrentDuplicate_NoOrphan asserts the invariant: SELECT COUNT(*) FROM projects WHERE host_path = ? == 1 after two parallel posts. 2. workspaceprojects.Link checked precondition + did INSERT in two separate queries — race window where the project could be deleted between the SELECT and INSERT surfaced as a 500 instead of 404. Rewritten as a single INSERT ... SELECT ... WHERE EXISTS, with a follow-up diagnostic SELECT when RowsAffected == 0 to return the right 404/422 reason. 3. TestDeleteProject_CascadesGitRepoAndMembership now explicitly asserts SELECT COUNT(*) FROM workspace_projects WHERE project_path = ? == 0 (instead of relying on UNIQUE-retry inference). Resolves Fix #5, #6, #15, #16. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Set make_latest: "legacy" so GitHub determines the latest release
based on semantic versioning rather than marking every new release
as latest regardless of version order.
https://claude.ai/code/session_01QBX4wtsg4wwyhcyZhG7GpS
Note
Low Risk
Low risk workflow change limited to GitHub Release metadata; the main impact is which tag gets marked as the repository’s “latest” release.
Overview
Updates the
release-cli.ymlGitHub Actions workflow to setmake_latest: "legacy"on thesoftprops/action-gh-releasestep so GitHub determines the “latest” release using semantic version ordering instead of always marking the newly created release as latest.Written by Cursor Bugbot for commit b2be20a. This will update automatically on new commits. Configure here.