Skip to content

standing-pr update: bail while a release is untagged, and reconcile from the latest main #799

Open

Description

@goosewobbler

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.

Activity

  1. added this to the 0.43.0 milestone on Oct 24, 2026
  2. goosewobbler commented on Oct 24, 2026

    @goosewobbler
    OwnerAuthor

    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.

    Time Event
    20:06:49 Standing PR webdriverio/desktop-mobile#781 merges: commit cc663e77, which bumps the Dioxus group's manifests to 1.1.0.
    20:06:52 The push run detects the merge and dispatches the publish, which starts at 20:12:15.
    20:13:29 A later PR, webdriverio/desktop-mobile#786, merges on top as 0666d533. Its push starts a standing-PR update.
    20:17:55 The publish pushes the @v1.1.0 tags.
    20:20:04 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    status:agent-readyDefined and ready for an autonomous (AFK) agent to pick uptype:bugSomething isn't working

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions