Summary
On a scheduled pipeline, command: complete (with --release-version explicitly passed) moves all not-Done issues from the targeted release into a freshly-created version-less "New release", leaving the original release without those issues. This silently fragments release attribution.
We hit this on 2026-06-02 when shipping v1.1.0 — 14 in-QA issues were orphaned into a blank "New release" entity, and we had to manually re-attach them via raw GraphQL.
Action version: 4819f7e30a7625793ff1b6ee015aa451123d339b (v0.11.2), CLI v0.11.2.
Workflow shape
- uses: linear/linear-release-action@4819f7e30a7625793ff1b6ee015aa451123d339b # v0.11.2
with:
access_key: ${{ secrets.LINEAR_ACCESS_KEY }}
command: complete
version: v1.1.0 # explicit version
stage: productionObserved behavior
- Action's
sync (at prior stage) had correctly populated v1.1.0 release with ~120 issues.
- Issues mostly at "In Progress" or "QA" workflow state (Linear-side, not Released stage on the release).
complete ran. Targeted version was v1.1.0 (explicit).- Result in Linear:
v1.1.0 release: stayed at its previous stage, but 14 issues that were still in QA/In Progress got detached and moved to a new release- A new release was created with name "New release", version blank, containing those 14 issues
- The 14 issues no longer had Linear-side attribution to v1.1.0 — they were on a phantom release we never asked for.
Expected behavior
complete --release-version=v1.1.0:
- Marks the v1.1.0 release as Released (stage transition)
- Leaves attached issues attached (regardless of issue workflow state)
- Does NOT create a new release
The issue's Linear workflow state (In Progress / QA / Done) is independent of the release's stage. Detaching them based on issue state is the surprising part.
Our workaround
We replaced complete with a raw-GraphQL releaseUpdate(stageId: <Released>) mutation, then an issue re-attach loop that polls until the attachment is stable (out-waits an async detach sweep we observed ~60-120s after the stage flip). See .github/scripts/linear-mark-released.sh in our repo if helpful.
This works but the workaround is ~150 LOC of bash + GraphQL + state coordination. Would much prefer the action's complete to do the right thing.
Secondary: update/complete dry-run output is opaque
Related issue we hit while evaluating v0.14.2:
For command: update with explicit --release-version, the dry-run output always reads:
{"level":"info","msg":"[dry-run] Would update release (current release) (version: vX.Y.Z) to stage <stage>"}
Three problems with this:
- "(current release)" wording suggests the CLI may not respect
--release-version and instead operates on Linear's "current" in-progress release.
- Says "Would update" even when
vX.Y.Z is a clearly non-existent version (we tested v999.999.999 — got the same line).
- Says "Would update … to stage staging" against an already-Released release with no warning that this would un-flip the release backward. We have no way to verify whether this is the actual behavior or just opaque dry-run logging.
If update does respect the explicit version, the dry-run output should reflect that (e.g., "Would update release v1.1.31 (currently at stage X)"). If it doesn't, that's also worth knowing — the operation we want is "flip THIS specific release to this stage."
This blocks us from confidently planning a sync → update stage transition in our prod-deploy flow. We dropped update from our upgrade scope as a result and use sync for everything.
Asks
- Fix
complete so it doesn't move not-Done issues to a new release. The release-stage transition shouldn't depend on individual issue workflow states.
- Improve
update (and complete) dry-run output to explicitly name the target release version and stage, and warn (or error) when the operation would un-flip a Released release or target a non-existent version.
Happy to add reproduction details or test our setup against a fix if useful.
Summary
On a scheduled pipeline,
command: complete(with--release-versionexplicitly passed) moves all not-Done issues from the targeted release into a freshly-created version-less "New release", leaving the original release without those issues. This silently fragments release attribution.We hit this on 2026-06-02 when shipping v1.1.0 — 14 in-QA issues were orphaned into a blank "New release" entity, and we had to manually re-attach them via raw GraphQL.
Action version:
4819f7e30a7625793ff1b6ee015aa451123d339b(v0.11.2), CLI v0.11.2.Workflow shape
Observed behavior
sync(at prior stage) had correctly populatedv1.1.0release with ~120 issues.completeran. Targeted version wasv1.1.0(explicit).v1.1.0release: stayed at its previous stage, but 14 issues that were still in QA/In Progress got detached and moved to a new releaseExpected behavior
complete --release-version=v1.1.0:The issue's Linear workflow state (In Progress / QA / Done) is independent of the release's stage. Detaching them based on issue state is the surprising part.
Our workaround
We replaced
completewith a raw-GraphQLreleaseUpdate(stageId: <Released>)mutation, then an issue re-attach loop that polls until the attachment is stable (out-waits an async detach sweep we observed ~60-120s after the stage flip). See.github/scripts/linear-mark-released.shin our repo if helpful.This works but the workaround is ~150 LOC of bash + GraphQL + state coordination. Would much prefer the action's
completeto do the right thing.Secondary:
update/completedry-run output is opaqueRelated issue we hit while evaluating
v0.14.2:For
command: updatewith explicit--release-version, the dry-run output always reads:Three problems with this:
--release-versionand instead operates on Linear's "current" in-progress release.vX.Y.Zis a clearly non-existent version (we testedv999.999.999— got the same line).If
updatedoes respect the explicit version, the dry-run output should reflect that (e.g.,"Would update release v1.1.31 (currently at stage X)"). If it doesn't, that's also worth knowing — the operation we want is "flip THIS specific release to this stage."This blocks us from confidently planning a sync → update stage transition in our prod-deploy flow. We dropped
updatefrom our upgrade scope as a result and usesyncfor everything.Asks
completeso it doesn't move not-Done issues to a new release. The release-stage transition shouldn't depend on individual issue workflow states.update(andcomplete) dry-run output to explicitly name the target release version and stage, and warn (or error) when the operation would un-flip a Released release or target a non-existent version.Happy to add reproduction details or test our setup against a fix if useful.