Repository navigation
Complete the Platform release left after a rejected notes push #4839
Description
🤖 Generated by the Agentic Engineer
Description
Platform's protected release pipeline created v1.222.1, then stopped before publishing its GitHub release. The tagged revision is deployed, but the normal release record is missing. Recovery must account for those partial effects rather than treating the failed job as an operation that changed nothing.
Steps to Reproduce
- Inspect Release run 38418390528, attempt 1, at merged main
607fd864e98d7883274270d0737934963039407c. - The release job selects v1.222.1, then GitHub rejects the push of
refs/notes/semantic-release-v1.222.1with the generic remote result(failed). - The v1.222.1 tag resolves to that source commit. Its release-note ref and GitHub release both return 404 in fresh authenticated reads.
Expected Behavior
Determine the reason for the rejected ref and recover the missing publication through the reviewed release path. Retain the existing tag and exact source identity; preserve provenance, current-main admission, credentials, protections and failure propagation. Verify the published outcome separately from the job conclusion.
Actual Behavior
The run is terminal failure, with a tag present and publication absent. The previous v1.222.0 release-note ref exists, so a blanket claim that this pipeline cannot write notes is unsupported. The log does not establish a transient cause or a permission change. The pinned shared workflow invokes semantic-release without a separate partial-publication recovery path; no blind retry, tag replacement or manual publication was performed during diagnosis.
Acceptance Criteria
- Establish the failed Git-ref operation's cause without publishing credential-bearing transport details.
- Prove a bounded recovery from the observed tag-present/release-absent state, keeping the existing tag and source identity and refusing mismatched or ambiguous observations.
- If shared release behavior needs a code repair, deliver it in the maintained catalogue first and mirror only the urgent compatible legacy requirement.
- Run the reviewed recovery and verify v1.222.1 publication, source binding and the required provenance; record any remaining partial state explicitly.
- Add regression coverage for partial publication and failed observations if a workflow or helper changes. Do not relax checks or force-push release refs.
High priority: this is a current failed post-merge publication, ahead of new product work. Medium estimated effort covers cause analysis, any narrowly scoped recovery implementation, review and real publication verification. This issue does not establish portal retirement or authorize production cleanup; retained-storage protection remains #4819, under its existing owner.
Part of #2043.
Activity
chore: agent-claim #4839 nonce=9845c4a1eb05991028b84578132c1d95
chore: agent-claim #4839 nonce=3df340cbf389596edcd22cce5b7ddb59
chore: agent-claim #4839 nonce=d8ec0113c1184a82906b440bcbf8d3a0
chore: agent-claim #4839 nonce=ded1bcea1fc5365bdb6b640aa5a0fb4f
chore: agent-claim #4839 nonce=7967dfceaa2d31f958f0966c72e12a36
devantler commentedon Oct 13, 2026
The subsequent green run did not recover publication. Release run 38422957712 completed successfully at
515eece3c6204d2b90b823b96b64d815c6d50dd8. Its actual job 115384814600 recognizes v1.222.1 as the last release, sees only the later dependency commit, then reports that no relevant changes exist and releases no new version. The latest published-release listing still ends at v1.222.0.This joins the failure with its partial effect: the tag exists, the original notes push failed, and the next normal invocation treats that tag as delivered. A green release job is therefore not publication recovery. Re-running the same workflow without addressing this state would not establish the missing outcome.
The next engineering step is to identify the rejected ref's cause and prepare a reviewed recovery that binds the existing tag to its captured source, refuses partial or changed reads, and verifies the resulting publication and provenance. Shared behavior belongs in the maintained catalogue first; the legacy caller remains only an urgent compatible consumer. No retry, manual publication, ref replacement or production mutation was performed by this run. The consumer and release jobs must keep their existing protection and credentials.
chore: agent-claim #4839 nonce=32793aac041d529f87db839722723942
chore: agent-claim #4839 nonce=ac88cd915cbdac0cb718050098856196
devantler commentedon Oct 13, 2026
Recovery prerequisite established: maintained catalogue issue devantler-tech/.github#587 now owns the shared, default-off release-recovery path. Its Bug type, High priority/effort, native parent #287 and public-board Backlog membership were read back. This incident has the native blocked-by relationship to that issue; recovery is not implemented or executed.
The later Release run 38425819758 also completed successfully at
bebac7b8cb43e3ff420fd3b05b5b52c84f8a3b48while recognizing v1.222.1 and publishing no new version. Fresh release-by-tag still returns 404 and the published list still ends at v1.222.0.I exercised the maintained catalogue's actual semantic-release 25.0.3 command against disposable local Git remotes with no credentials. The ordinary fix control selects v1.2.4; adding that tag to the same fix commit makes the command succeed without selecting a new release. All twelve release-decision controls passed, with files and refs unchanged. The fixture omits the GitHub publisher as the existing offline fixture requires, so it proves the tag-based no-op decision, not real publication or the original remote rejection's cause.
The exact upstream release sequence pushes the tag and channel note before publication; last-release selection uses the tag. This explains the later no-op. The original notes-ref rejection remains UNKNOWN: its generic remote failure does not establish a transient error or permission drift.
Next: deliver the reviewed recovery in the maintained catalogue, mirror only the urgent compatible legacy requirement, then complete and independently verify this captured tag/source through the protected path. No release ref was removed, replaced or force-pushed; no retry, publication or production mutation was performed. Keep this incident open.
chore: agent-claim #4839 nonce=5e66385217a7bbb35ce95c3742588af6
chore: agent-claim #4839 nonce=31703b824ff65ffa70c5b4ee3cb8de8e
devantler commentedon Oct 14, 2026
The same partial-publication failure has now recurred for v1.223.3. Release run 38573634755, attempt 1, failed at merged source
e58cd06b62207292fe636e3ccf568db823333f9fafter GitHub rejected the channel-note ref push. The existing version tag resolves to that exact source; fresh authenticated reads find no GitHub release and no matching channel-note ref. The source came from #4882, independently verified merged at its expected head.This is additional evidence for this incident and its existing maintained prerequisite, devantler-tech/.github#587. It does not replace the original v1.222.1 recovery obligation. The generic remote rejection still does not establish a service fault or permission change, and a tag is not proof of publication.
Keep both captured tag/source pairs intact. The next delivery is the reviewed GitHub-only recovery path in the maintained catalogue, followed by the compatible legacy consumer rollout and independently verified publication. No blind retry, manual release, tag replacement, ref force-push, credential change or production mutation was performed.