🐛🧑‍💻 - Tag push createrelease loses the explicit Action issue and blocks finalization after all packages publish

Is there an existing issue for this?

I have searched the existing issues.

Exact searches for create_release + workflow.stale returned no issue. single-action-issue + push returned unrelated historical feature requests296/239/233. Searches also found related520/622, but this reproducer loses an explicit Action issue on a tag-push event before GitHub Release creation, after all package publication succeeds. It is distinct from the consumer's optional-check diagnostic report728 and false-positive report739.

Which actions are affected?

Issue, Commits

Which platforms are affected?

Linux

Description

The valid single-action-issue Action input is not honored when create_release executes from push of a version tag. The source-level issue resolver prioritizes branch-derived event inference before the already-parsed Action issue. A tag such as v1.5.3 has no issue-bearing branch name, so setup resolves no issue and does not restore the durable operation. create_release then returns workflow.stale, despite its requested issue, operation ID and version matching the real stored operation. All registry packages have already been published at this point.

Actual production case: vypdev/zstandard issue175, promotion PR176, immutable v1.5.3:

Frozen candidate/source: d80fb5335d9de5fd2cbc7e2007954f0b9a1075a5; candidate tree 36ccfe6582bbd6eb4b619bb9bae02d8789cb67e8.
Accepted production/tag: 60ac0b924549e3bfc14d45ab217bdc42519bbe64, with the exact candidate tree and normal merge parents aca7c1162962d59a2c7287871c95868e34c97e0e + candidate. Full preparation40439638708 and promotion PR technical CI passed before acceptance.
Operation: 1c7de59b-a676-4b59-9e03-db65d3a5ebb9; version1.5.3; strategyproduction-lineage; promotionPullRequest176.
Publisher run40449489903, attempt2, eventpush, refv1.5.3, exact head/production above.
Validator122075309505: success, including immutable tag, successful preparation/accepted Copilot promotion and metadata checks.
Publication122075445098: success. It safely reused eight packages from attempt1 and published the remaining CLI/main packages after their private administrator corrected GitHub publishing configuration.
Public verification122077606013: success, all ten exact1.5.3 versions. Independent read-only downloads also verified all ten archive hashes and pubspec bytes, and all nine generated CLI/Web assets, against the frozen candidate. CLI1.5.3 and main1.5.3 are public.
Finalization122077928789: fails immediately inside create_release, reference 9d689dfc-644d-42c6-955a-b9699c6ac7f6. No GitHub Release1.5.3 exists; attaching checksums and published_deployment_action are skipped, so normal development reconciliation cannot start.

The Action log explicitly shows the correct inputs:

single-action: create_release
single-action-issue: 175
single-action-operation-id: 1c7de59b-a676-4b59-9e03-db65d3a5ebb9
single-action-version: 1.5.3
issue-workflow-profile: {"schemaVersion":1,"enabled":["feature","bugfix","documentation","chore","help","hotfix","release"]}

The actor and configured PAT user are both vypbot; the explicit valid single action is admitted and executes. No credential contents are part of this report.

Durable state is not newer or mismatched: before and after finalization, the same operation remains revision6, phaseblocked, lastFailure categorypublication, retryabletrue, previousPhasepublishing, publicationVerifiedfalse; source, production, version and promotion PR remain unchanged. The earlier block came from the now-corrected private CLI setting. The current continuation guard already accepts a retryable blocked operation's previous phase. We are not attributing this to a missing blocked-phase allowance.

The source boundary explains the missing-operation result:

github_event_inputs.ts projects the actual GitHub event payload; an ordinary tag-push payload has no raw single-action-issue property.
setup_execution_boundary.ts derives configuredSingleActionIssue only from that raw event input object, reader at234. The validated Action input remains separately present as singleAction.issue=175.
resolveSingleActionIssueNumber handles context.isPush by extracting an issue from the ref before the configured single-action fallback. v1.5.3 produces no issue.
Setup returns issue-unresolved; the application boundary returns early. projectDeploymentPublicationContext can only copy the restored current configuration, which is absent in this route.
create_release_workflow.ts invokes the guard; missing operation becomes generic workflow.stale. The source-level chain is reproduced below; the production run was not instrumented to reveal an internal context or the underlying guard message.

Expected: explicit, validated single-action targeting should be honored independently of the surrounding tag/branch event, while preserving repository authorization, operation identity/version, accepted production and publication proof checks. Real stale operations must still be rejected. A failure caused by missing context should not be presented only as a newer state superseding an invocation when that is not the observed cause.

Reproducing the issue

Production route: invoke the consumer tag-triggered publisher above with the logged inputs. Publication and exact-version verification succeed, but create_release fails before creating the release. Do not republish packages or mutate tags to reproduce the resolver locally.

Executed isolated source-level reproduction, Node24.20.0 on macOS arm64: download the exact upstream policy and its three dependencies at the source revision above; execute those files unmodified in vm.SourceTextModule after Node's built-in stripTypeScriptTypes. Link only the actual positive_integer_policy.ts, action_types.ts and title_utils.ts modules. Fixture repository readers implement isPullRequest=false, isIssue(number)=number===175, getHeadBranch=undefined. No network, credentials, provider writes, repository edits or publication occurs.

Call resolveSingleActionIssueNumber with isSingleAction=true, singleAction.currentAction='create_release', singleAction.issue=175, raw configured issue absent, event-level issue/PR numbers-1, and compare:

Context	Actual resolved issue	Honors Action issue175	Fixture queries
push, ref`v1.5.3`, isPushtrue	undefined	no	none
same input, workflow_dispatch, isPushfalse	175	yes	isPullRequest175; isIssue175
push, but reviewed explicit issue duplicated in raw configured field	175	yes	none
push, branch`feature/99-fixture`, same Action issue175	99	no	none

All four observed-result assertions pass. The third row is a control, not a proposed workaround that forges a GitHub event payload. The fourth is a pure resolver observation; we have not demonstrated any unauthorized cross-issue provider mutation.

Exact source SHA256 values used by this reproduction:

execution_issue_number_policy.ts f7791178d64eb25d2c72e0feaa2361de5c8c131259124c3f34bf74462efb275a
positive_integer_policy.ts       319539291fb947af7884bc160282de6f0b1f14958ab40a001eec59925dcfe9c2
action_types.ts                  8e76b0f73f1be5c0bbd2f990234397f0d087546b2b02570eef94b557e2dfd271
title_utils.ts                   a986fc92abd55177355620e94b581049a332d8cb3a5d79fd27521a9f73c47d89

Suggested upstream coverage: actual GitHub Action input projection plus setup plus publication dispatch on a tag-push event; preserve INITIAL_SETUP's repository-only semantics and no-issue sentinels; cover explicit issue against issue/PR/push events, branch inference when no explicit issue exists, mismatched operation/version, retryable blocked publication, stale/nonretryable state, and no provider mutation before identity proof. Existing direct use-case tests seed a prepared configuration and do not by themselves exercise this event/input boundary.

copilot Version

vypdev/copilot@v3, real download resolved to 39679e26a22b40a5a4a40e8f167f46273157182e (3.10.5), Linux ubuntu-runner-3 for finalization; failure reporter on ubuntu-runner-2. Source SHAs/permalinks here identify executed diagnostics only; the consumer continues to configure version-tag Action references.

Relevant Log Output

2026-10-27T08:04:34.4950485Z Download action repository 'vypdev/copilot@v3' (SHA:39679e26a22b40a5a4a40e8f167f46273157182e)
2026-10-27T08:04:40.4518885Z User from token (vypbot) matches actor. Executing single action: create_release.
2026-10-27T08:04:40.4596161Z Executing CreateReleaseUseCase.
2026-10-27T08:04:40.4616234Z Publishing result: 1 result(s), 0 step(s), 1 error(s).
2026-10-27T08:04:40.4631703Z Configuration persistence skipped: this single action does not modify execution configuration.
2026-10-27T08:04:40.7773547Z Impact: A newer state superseded this workflow invocation.
Error code: workflow.stale
Action: Inspect the current state and start a fresh invocation only if needed.
Retained state: Existing persisted state and completed external effects were preserved.
Retryable: No
Reference: 9d689dfc-644d-42c6-955a-b9699c6ac7f6

The separate generic optional Check Run warning repeats728. Reporter122078013058 deliberately reports the finalization failure and retains state; referencef5858be5-86a3-4c27-994d-31047e1e8af8. Its expected red result is not being reported as another defect. The earlier CLI administrator-setting failure is also not attributed to Copilot.

Additional context and comments

The maintainer explicitly requested that any anomalous Copilot behavior be reported here with detailed evidence, with engine fixes left to Copilot maintainers. We have not modified Copilot code, generated workflows, installed profile, credentials, approval policy or durable operation state, created a manual GitHub Release/back-merge, forged a publication receipt or moved any tag. Historical1.5.1/1.5.2 remain untouched;1.5.3 package publication is complete but GitHub Release/checksum finalization and development reconciliation remain pending.

Please provide the upstream correction and supported recovery for this already published operation. Blindly rerunning the same tag-push entry repeats the demonstrated input-resolution defect; resuming reconciliation alone requires a publication receipt that this blocked finalization has not produced. We will retain the accepted operation/tag and resume through the supported action once available.

@vypbot

Hi! I’m @vypbot, the Copilot assistant for this repository.

I can answer questions, explain the codebase, propose implementation and test plans, review issues and pull requests for potential bugs or security problems, and help authorized maintainers apply changes.

Try /copilot help to see the available commands, or mention @vypbot with your question.

Implementation plan

Current status: Ready to start. No action is required from maintainers before implementation.

Define issue resolution precedence
- Honor a validated single-action issue independently of push refs, while retaining repository authorization and issue or pull request validation.
- Use branch or event inference when no explicit issue is configured; preserve INITIAL_SETUP repository-only behavior and no-issue sentinels.
Propagate the validated Action input
- Carry singleAction.issue through setup and publication context restoration without relying on a raw GitHub event payload field.
- Keep operation ID, version, accepted production, and publication proof checks intact before release creation.
Add boundary and regression coverage
- Cover tag-push and issue, pull request, and workflow_dispatch events through Action input projection, setup, and publication dispatch.
- Verify inferred-issue behavior, mismatched operation or version, retryable blocked publication, stale or nonretryable state, and no provider mutation before identity proof.
Clarify continuation failures
- Report missing issue or operation context distinctly from a newer state superseding the invocation.

Acceptance: An end-to-end test using a tag-push event and validated single-action-issue 175 restores the matching retryable operation and reaches create_release identity checks without provider mutation beforehand; mismatched identity and stale or nonretryable operations remain rejected.

Need something else? Mention the bot with a question or use /copilot help.

Issue closed — historical progress

Current status: closed as completed.

The last estimate is retained below as history. Closure does not certify a new percentage, tests, or branch alignment.

Action required: none for this closed issue. If work continues, reopen the issue; a fresh assessment can update this same card.

Last assessment before closure (historical)

Progress: 75% — in progress

> Current status: [R1] Expected: explicit, validated single-action targeting should be honored independently of the surrounding tag/branch event, while preserving repository authorization, operation identity/version, accepted production and publication proof checks. Real stale operations must still be rejected. A failure caused by missing context should not be presented only as a newer state superseding an invocation when that is not the observed cause. — The resolver prioritizes a positive validated Action issue; release creation retains its operation, version, phase, and accepted production SHA guards. Missing operation context receives a distinct configuration error. The patch shows implementation, not executed verification.
[R2] Please provide the upstream correction and supported recovery for this already published operation. Blindly rerunning the same tag-push entry repeats the demonstrated input-resolution defect; resuming reconciliation alone requires a publication receipt that this blocked finalization has not produced. We will retain the accepted operation/tag and resume through the supported action once available. — Documentation and recovery messaging direct operators to restore verified context and retry the supported workflow with the same operation ID and version, preserving existing state and completed effects. Execution of this recovery is not independently verified.
[R3] "Honor a validated single-action issue independently of push refs, while ret
[untrusted content truncated]

Next: [R8] "Verify inferred-issue behavior, mismatched operation or version, retryable blocked publication, stale or nonretryable state, and no provider mutation before identity proof." — Independently verify the required behavior and no-provider-mutation checks in the covered cases.
[R10] "acceptance": "An end-to-end test using a tag-push event and validated single-action-issue 175 restores the matching retryable operation and reaches create_release identity checks without provider mutation beforehand; mismatched identity and stale or nonretryable operations remain rejected." — Independently verify the end-to-end test passes and confirms rejection of mismatched identity and stale or nonretryable operations.

Issue closed: synchronization recommendation retired

No branch synchronization is required for this closed issue.

The previous recommendation is historical. Issue closure does not certify that the branches are synchronized.

Production verification with the released fix: the existing unchanged vypdev/copilot@v3 reference now resolves to f5e5a4cf9a80248994469cd88ad55eecab5b95ca (3.10.6). The four original isolated issue-resolution controls now all honor explicit issue175, including tag push and an unrelated issue-bearing branch. Exact upstream Git blobs were checked; no consumer Copilot code or configuration was patched.

The real 1.5.3 workflow, attempt3 has now completed successfully:

Validator123031685987 reverified the immutable tag, accepted promotion/preparation and generated metadata.
Publisher123033251432 safely reused all ten already published1.5.3 versions; no new version or tag was created.
Public version verification123034962751 succeeded.
Finalization123035203541, the previously blocked route, now succeeded with the real tag-push event and explicit issue175/operation/version.
Copilot created GitHub Release1.5.3, releaseID427073919. Attached checksums.txt, asset686024450, SHA25656b0e3e6650af51d6b44350d85eb5f3b79c2cb9ba645ac6ddf5d2a8e32160417; all nine entries match the frozen candidate and published archive assets.
The normal publication callback recorded publicationVerifiedtrue and a real publication receipt, revision11, then created reconciliation PR178 from accepted production into develop.

The same operation1c7de59b-a676-4b59-9e03-db65d3a5ebb9, sourced80fb5335d9de5fd2cbc7e2007954f0b9a1075a5, production/tag60ac0b924549e3bfc14d45ab217bdc42519bbe64 and tree36ccfe6582bbd6eb4b619bb9bae02d8789cb67e8 are retained. Historical1.5.1/1.5.2 tags remain untouched; no durable-state reset, forged event, manual release or separate back-merge was used.

The reconciliation PR is held for its complete technical CI. Its Apple-host disk-exhaustion failures are a separate infrastructure problem, and the unrelated new review false positive is reported in770. The actual finalization and subsequent publication/reconciliation hooks covered by740 are now working in production.

Navigation Menu

Repository navigation

🐛🧑‍💻 - Tag push createrelease loses the explicit Action issue and blocks finalization after all packages publish #740

Is there an existing issue for this?

Which actions are affected?

Which platforms are affected?

Description

Reproducing the issue

copilot Version

Relevant Log Output

Additional context and comments

3 remaining items

Implementation plan

Issue closed — historical progress

Last assessment before closure (historical)

Progress: 75% — in progress

Issue closed: synchronization recommendation retired

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

🐛🧑‍💻 - Tag push createrelease loses the explicit Action issue and blocks finalization after all packages publish #740

Description

Is there an existing issue for this?

Which actions are affected?

Which platforms are affected?

Description

Reproducing the issue

copilot Version

Relevant Log Output

Additional context and comments

Activity

vypbot commented on Oct 27, 2026

3 remaining items

vypbot commented on Oct 28, 2026

Implementation plan

vypbot commented on Oct 28, 2026

Issue closed — historical progress

Last assessment before closure (historical)

Progress: 75% — in progress

vypbot commented on Oct 28, 2026

Issue closed: synchronization recommendation retired

efraespada commented on Oct 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions