You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
standing-pr update: bail while a release is untagged, and reconcile from the latest main #799
Part of #790 (option 1). It's a code change, so it doesn't wait on the workflow work. Start after #794 merges, since both change runStandingPRUpdate.
Problem
An update that runs while a standing-PR publish is in flight sees the merged release commit's bumped package.json before the release's tags exist, and double-bumps. The mid-run guard in runStandingPRUpdate only bows out when the release commit is HEAD, so a feeder commit on top defeats it.
Fix
Bail while a release is untagged. The update bows out, with a reason, while main holds a release commit whose release tags don't exist yet. The signal is a merged standing PR's manifest tags missing from the remote, or a direct release commit with none of its tags.
But don't stall updates after a failure. It proceeds anyway when that release has a failure report (the publish failed, so the next release supersedes it). It also proceeds when the release commit is older than a backstop, about two hours, so a publish that crashed without reporting can't stall updates for good. Log a warning when the backstop applies.
Reconcile against the latest main. Make the reconcile run by refresh-after-release analyse origin/<base> rather than the job's checkout. Today the dry run happens before resetReleaseBranch fetches, so in a publish job it analyses the tagged merge commit and can close a standing PR an update just opened.
Restore the publish jobs' reconcile. Then end the example's publish and retry-publish jobs with refresh-after-release again, so the standing PR is rebuilt once the tags exist.
Acceptance criteria
Through runStandingPRUpdate, with the fake forge and fake git:
an untagged release commit with a feeder commit on top returns a noop with the reason;
the same with a failure report proceeds;
the same past the backstop proceeds with a warning.
A reconcile run inside a publish job's checkout analyses origin/main, and rebuilds rather than closes a standing PR that holds a newer feeder.
A real occurrence, in webdriverio/desktop-mobile on 2026-10-24 (UTC), which matches the problem described here. A later commit on top of the release commit defeated the guard.
The update, working from a checkout taken before the tags existed, opens webdriverio/desktop-mobile#787, offering all five Dioxus packages at 1.2.0. It lists every change since the 1.0.0 tags, all of which had just shipped in 1.1.0.
20:24:07
The publish completes.
20:27:28
Another merge, webdriverio/desktop-mobile#788, starts an update that runs after the tags exist. It finds nothing to release and closes #787 at 20:28:16.
The recovery depended on an unrelated push arriving after the tags. Our publish path is the standing-PR publish, which doesn't run refresh-after-release, so without #788 the stale standing PR would have stayed open until the next merge. That supports the "Restore the publish jobs' reconcile" item.
Activity
goosewobbler commentedon Oct 24, 2026
A real occurrence, in webdriverio/desktop-mobile on 2026-10-24 (UTC), which matches the problem described here. A later commit on top of the release commit defeated the guard.
cc663e77, which bumps the Dioxus group's manifests to 1.1.0.0666d533. Its push starts a standing-PR update.@v1.1.0tags.The recovery depended on an unrelated push arriving after the tags. Our publish path is the standing-PR publish, which doesn't run
refresh-after-release, so without #788 the stale standing PR would have stayed open until the next merge. That supports the "Restore the publish jobs' reconcile" item.