🐛🧑‍💻 - Cancelled PR linking loses original base and recovery marker after a newer invocation #785

Is there an existing issue for this?

• I have searched the existing issues. 📝 - Document temporary PR base retargeting for issue linking in installed agent guidance #759 describes the intended temporary retargeting; this report concerns interrupted restoration and loss of its recovery marker.

Which actions are affected?

Pull Request

Which platforms are affected?

Linux

Description

Cancelling a PR analysis during its temporary issue-link retarget can leave the PR targeting the production/default branch. A subsequent invocation generated a new description and persisted that transient base as parentBranch, removing the pending recovery marker. The intended target in the admitted issue and the contributor's PR creation was develop.

This is not a complaint about the intentional temporary retarget documented in #759. The defect is that cancellation prevented restoration and later processing erased the evidence needed to restore the original target.

Observed consumer: vypdev/zstandard issue #177, draft PR #183. No merge or deployment occurred. Copilot's code, installed workflows and configuration have not been modified. The PR has now been returned to develop through a normal maintainer PR metadata update; no managed Git branch/ref was rewritten.

Reproducing the issue

1. Admit a bugfix issue whose Action-selected parent is develop and let the Action create its managed branch.
2. Open its PR with gh pr create --base develop (not the repository default master).
3. Start native PR processing. It appends the pending issue-link marker and temporarily changes the base to the default branch.
4. Push another normal commit while the linking workflow waits. The installed PR job has cancel-in-progress: true, so the earlier invocation is cancelled before its restoration finally-block completes.
5. Observe that the PR remains on master. Allow the synchronize event to process the current body. In this incident the rewritten body no longer contained the pending marker and its embedded configuration used parentBranch: master.
6. Re-running the original PR job on the original event did not restore the original target in this incident; attempt 2 ended workflow.stale after processing a newer head. Its log used develop for the diff only after the maintainer restored that base.

Expected: after any cancellation/retry, the final PR target and persisted parent remain the admitted develop, or the operation fails closed with actionable recovery state that subsequent description updates cannot discard. A temporary default target should never become the settled parent merely because the worker was terminated.

copilot Version

vypdev/copilot@v3, version 3.10.6, resolved engine commit f5e5a4cf9a80248994469cd88ad55eecab5b95ca in the affected run. The installed Action references remain version tags.

Relevant Log Output

Run 40849860701, attempt 1, job 123366350392, head 44e4203b502cb02a21723015b810cf8f209359ed
2026-10-29T09:31:31.2485316Z pending marker:
<!-- copilot:pr-issue-link:v1;pr=183;issue=177;base=develop;state=pending -->
2026-10-29T09:31:32.6125241Z Changed base branch to master
2026-10-29T09:31:42.8048229Z workflow cancelled

Later settled PR: draft=true, base=master, no pending marker
Embedded PR configuration: parentBranch=master
Issue's admitted managed branch parent: develop

Original-job rerun: run 40849860701, attempt 2, job 123402291364
2026-10-29T10:50:35.7887032Z Impact: A newer state superseded this workflow invocation.
Error code: workflow.stale

Additional context and comments

• PR: fix: Android fails to resolve native sources from the Pub cache on Windows (#177) zstandard#183
• Issue: 🐛🧑‍💻 - Android fails to resolve native sources from the Pub cache on Windows zstandard#177
• Interrupted run: https://github.com/vypdev/zstandard/actions/runs/40849860701/attempts/1
• Original-event retry: https://github.com/vypdev/zstandard/actions/runs/40849860701/attempts/2
• Native source inspected read-only: src/application/usecases/steps/pull_request/link_pull_request_issue_workflow.ts at the engine commit above. It records the original base in a pending suffix, waits, and restores in finally. Its documented immutable-payload recovery is useful, but needs to remain effective after cancellation and later PR-description writes.
• Timeline's base change was by vypbot; the PR was explicitly created against develop. It was kept in draft and no auto-merge was enabled.
• Please cover cancellation/worker termination during the wait, a newer synchronize invocation arriving first, preservation of pending state across description/configuration updates, and retrying the original event after the head moves. Ensure final-base recovery does not depend on the contributor discovering and manually retargeting the PR.
• This is separate from routine workflow.stale diagnostics: the concrete issue is the wrong settled target plus removal of the durable restoration marker.