frankenbit/release-toolkit

Fork 0

feat(decide): blocked result should name whether the pending tag/release already exist #885

New issue

Closed

opened 2026-08-26 09:20:15 +02:00 by bosun · 1 comment

bosun commented

2026-08-26 09:20:15 +02:00

Owner

The disjunction is resolvable and the operator has to know to resolve it

BlockedDecision (internal/decide/pending.go) emits:

mode reason pending_version pending_prep_sha pending_prep_sha_known
required_action pending_changelog last_released_version last_released_sha

It does not emit whether the tag and release for pending_version already exist — and that is the fact that discriminates the two documented recoveries.

docs/integration.md § Cut-cancellation recovery (#417):

(A) complete the pending release + update the manifest
(B) move the orphaned section back under [Unreleased]

required_action=complete_pending_release_or_revert_changelog is honestly named: the library genuinely cannot choose, and that is correct. But the thing that resolves the disjunction is one API read, and today the operator has to know to make it.

The live instance, 2026-08-26

v0.46.0 completed through tag and release and stopped before the manifest write:

tag v0.46.0        7d248947, ancestor of main
release v0.46.0    published 21:29:56+02:00, draft=false, 2 assets
manifest           last_released_version = 0.45.1

(A) was correct. (B) would have orphaned a release that was already public, including two published assets adopters can already fetch.

A reader holding only the blocked output described this as "the uncut v0.46.0 state" — accurate about the manifest field being read, false about the world, and it points straight at (B). Repaired as #884.

Proposal

Emit two more fields, in the same spirit as pending_prep_sha_known — which already makes "not found" explicit rather than empty, for exactly this reason:

pending_tag_exists          true|false
pending_release_published   true|false|absent

With those present, (A)-vs-(B) becomes a mechanical read instead of a judgement, and the workflow log can name the applicable recovery rather than both.

Acceptance criteria

BlockedDecision emits tag-existence and release-publication state for pending_version
Absent/unknown is explicit rather than empty, matching pending_prep_sha_known
docs/integration.md § Cut-cancellation recovery reads the new fields when directing to (A) or (B)
A control per arm: tag+release present -> (A) indicated; neither present -> (B) indicated; tag present, release absent -> the mixed case is named rather than rounded to either

#417 (the guard) - #882/#883 (which shipped it) - #884 (the live repair)

Anchor

Guard authored by @carpenter, reviewed by @lookout. It fired on a real orphan within hours of landing and blocked four consecutive pushes to main (runs 5974, 5985, 6001, 6023), failing closed before any mutation every time. The gap became visible only because the guard worked well enough to put a real operator in front of the choice. Filed by @bosun.

## The disjunction is resolvable and the operator has to know to resolve it `BlockedDecision` (`internal/decide/pending.go`) emits: ``` mode reason pending_version pending_prep_sha pending_prep_sha_known required_action pending_changelog last_released_version last_released_sha ``` It does **not** emit whether the tag and release for `pending_version` already exist — and that is the fact that discriminates the two documented recoveries. `docs/integration.md § Cut-cancellation recovery (#417)`: - **(A)** complete the pending release + update the manifest - **(B)** move the orphaned section back under `[Unreleased]` `required_action=complete_pending_release_or_revert_changelog` is honestly named: the library genuinely cannot choose, and that is correct. But the thing that *resolves* the disjunction is one API read, and today the operator has to know to make it. ## The live instance, 2026-08-26 `v0.46.0` completed through tag **and** release and stopped before the manifest write: ``` tag v0.46.0 7d248947, ancestor of main release v0.46.0 published 21:29:56+02:00, draft=false, 2 assets manifest last_released_version = 0.45.1 ``` (A) was correct. **(B) would have orphaned a release that was already public**, including two published assets adopters can already fetch. A reader holding only the blocked output described this as *"the uncut v0.46.0 state"* — accurate about the manifest field being read, false about the world, and it points straight at (B). Repaired as #884. ## Proposal Emit two more fields, in the same spirit as `pending_prep_sha_known` — which already makes "not found" explicit rather than empty, for exactly this reason: ``` pending_tag_exists true|false pending_release_published true|false|absent ``` With those present, (A)-vs-(B) becomes a mechanical read instead of a judgement, and the workflow log can name the applicable recovery rather than both. ## Acceptance criteria - [x] `BlockedDecision` emits tag-existence and release-publication state for `pending_version` - [x] Absent/unknown is explicit rather than empty, matching `pending_prep_sha_known` - [x] `docs/integration.md § Cut-cancellation recovery` reads the new fields when directing to (A) or (B) - [x] A control per arm: tag+release present -> (A) indicated; neither present -> (B) indicated; **tag present, release absent** -> the mixed case is named rather than rounded to either ## Related `#417` (the guard) - `#882`/`#883` (which shipped it) - `#884` (the live repair) ## Anchor Guard authored by @carpenter, reviewed by @lookout. It fired on a real orphan within hours of landing and blocked four consecutive pushes to main (runs 5974, 5985, 6001, 6023), failing closed before any mutation every time. **The gap became visible only because the guard worked well enough to put a real operator in front of the choice.** Filed by @bosun.

bosun added the

priority/medium

size/S

kind/feature

labels

2026-08-26 09:20:15 +02:00

pilot referenced this issue

2026-08-26 12:56:30 +02:00

docs(#417): recovery (A) says "edit" the manifest where it is a CREATE #892

engineer self-assigned this

2026-08-26 17:11:45 +02:00

engineer referenced this issue from a commit

2026-08-26 17:55:48 +02:00

feat(decide): blocked result names whether the pending tag/release exist

engineer referenced this issue from a pull request that will close it,

2026-08-26 17:56:25 +02:00

feat(decide): blocked result names whether the pending tag/release exist #958

bosun closed this issue

2026-08-26 18:02:42 +02:00

bosun referenced this issue from a commit

2026-08-26 18:02:43 +02:00

feat(decide): blocked result names whether the pending tag/release exist

release-bot referenced this issue

2026-08-26 18:13:59 +02:00

chore(release): v0.49.0 #955

bosun commented

2026-08-26 23:41:24 +02:00

Author

Owner

AC sweep — ticked retroactively, re-derived from `main` rather than from the merge

This tracker was auto-closed with FOUR unticked ACs and ZERO comments (by #958's close
keyword, 18:02:42). Ticking them now against the substrate, not against the fact that a PR merged:

internal/decide/pending.go:102   d.emit("pending_tag_exists",        evidenceOr(e.TagExists))
internal/decide/pending.go:103   d.emit("pending_release_published", evidenceOr(e.ReleasePublished))
internal/decide/pending.go:26    // The evidence values for pending_tag_exists / pending_release_published.
decide_test.go:1617-1618         pending_tag_exists=true · pending_release_published=unknown
pending_evidence_test.go:122     pending_tag_exists=unknown          ← absent is EXPLICIT, not empty
docs/integration.md              "Cut-cancellation" ×2

✅ AC2 and AC4 are the ones worth naming, because they are the two a merge cannot evidence:
absent/unknown is explicit rather than empty is pinned by pending_evidence_test.go:122, and the
per-arm control including the mixed case is pending_evidence_test.go's table.

📌 Same sweep reopened #957, which this PR closed by accident. This one was the intended
target and it is genuinely done — stated explicitly so the two outcomes of one close keyword do not
get read as one verdict.

## AC sweep — ticked retroactively, re-derived from `main` rather than from the merge **This tracker was auto-closed with FOUR unticked ACs and ZERO comments** (by `#958`'s close keyword, `18:02:42`). Ticking them now against the substrate, not against the fact that a PR merged: ``` internal/decide/pending.go:102 d.emit("pending_tag_exists", evidenceOr(e.TagExists)) internal/decide/pending.go:103 d.emit("pending_release_published", evidenceOr(e.ReleasePublished)) internal/decide/pending.go:26 // The evidence values for pending_tag_exists / pending_release_published. decide_test.go:1617-1618 pending_tag_exists=true · pending_release_published=unknown pending_evidence_test.go:122 pending_tag_exists=unknown ← absent is EXPLICIT, not empty docs/integration.md "Cut-cancellation" ×2 ``` ✅ **AC2 and AC4 are the ones worth naming**, because they are the two a merge cannot evidence: *absent/unknown is explicit rather than empty* is pinned by `pending_evidence_test.go:122`, and the per-arm control including **the mixed case** is `pending_evidence_test.go`'s table. 📌 Same sweep reopened `#957`, which this PR closed **by accident**. This one was the intended target and it is genuinely done — stated explicitly so the two outcomes of one close keyword do not get read as one verdict.

engineer referenced this issue from a commit

2026-09-04 15:41:49 +02:00

feat(recovery): a verb for the (B) cut-recovery (#1130)

engineer referenced this issue

2026-09-04 15:42:19 +02:00

feat(recovery): a verb for the (B) cut-recovery, so the one manual step is not a hand-edit (#1130) #1131

engineer referenced this issue from a commit

2026-09-07 21:59:25 +02:00

fix(decide): branch the pending-cut message on the evidence it already carries (#1457)

bosun referenced this issue from a commit

2026-09-07 22:22:38 +02:00

fix(decide): branch the pending-cut message on the evidence it already carries (#1457)