Skip to content

fix: pass teamId when resolving state and labels in update/list commands#1

Open
Natsukingdom wants to merge 1 commit intorolaca11:mainfrom
Natsukingdom:fix/update-state-team-resolution
Open

fix: pass teamId when resolving state and labels in update/list commands#1
Natsukingdom wants to merge 1 commit intorolaca11:mainfrom
Natsukingdom:fix/update-state-team-resolution

Conversation

@Natsukingdom
Copy link
Copy Markdown

Summary

  • Fix issues update command: pass the issue's teamId to resolveStateId() and resolveLabelIds() in the flag-processing (non-interactive) branch
  • Fix issues list command: hoist the teamId variable so it can be passed to resolveStateId() when filtering by --state

Problem

In workspaces with multiple teams, the update and list commands resolve workflow state names (e.g. "Todo", "In Progress", "Done") without team context. Since every team typically has states with the same names, resolveStateId() picks the first match from any team, which may not be the correct one.

For issues update, this causes the Linear API to reject the update with:

Discrepancy between issue team and state, cycle or project

For issues list, filtering by --state combined with --team could silently use a state ID from the wrong team, returning incorrect results.

Root Cause

  • update command (flag-processing branch): resolveStateId(options.state) and resolveLabelIds(labelNames) were called without teamId, even though the resolveStateId() and resolveLabelIds() functions already accept an optional teamId parameter and the create command correctly passes it.
  • list command: The teamId variable was declared inside the if (teamFilter) block scope and was not accessible when resolving the --state filter.

Fix

  • update: Before resolving state/labels, fetch the issue's team ID via client.issue(issueId) and pass it to both resolveStateId() and resolveLabelIds(). The extra API call is only made when --state or --labels flags are provided.
  • list: Hoist the teamId variable (resolvedTeamId) outside the if (teamFilter) block so it can be passed to resolveStateId().

This aligns the update and list commands with the pattern already used in the create command (line 238 and 251 in the original code).

Test plan

  • Verify linear issues update ISSUE-ID --state "Done" works correctly in a multi-team workspace
  • Verify linear issues list --team TEAM --state "Todo" returns correct results filtered to the specified team's "Todo" state
  • Verify single-team workspaces are unaffected (teamId is optional, behavior unchanged when not provided)
  • Verify npm run build compiles without errors

🤖 Generated with Claude Code

In the `update` command's flag-processing branch, `resolveStateId()` and
`resolveLabelIds()` were called without passing `teamId`. In workspaces
with multiple teams that have identically-named workflow states (e.g.
"Todo", "In Progress", "Done"), this caused the resolver to pick the
first matching state from any team, which could belong to a different
team than the issue being updated. The Linear API then rejects the
update with: "Discrepancy between issue team and state, cycle or
project".

The fix fetches the issue's team ID before resolving state/labels and
passes it to both `resolveStateId()` and `resolveLabelIds()`, matching
the pattern already used in the `create` command.

Additionally, the `list` command had the same issue: the `teamId`
variable was scoped inside the `if (teamFilter)` block and not available
when resolving the `--state` filter. This is fixed by hoisting the
variable so it can be reused.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@Natsukingdom Natsukingdom marked this pull request as draft March 2, 2026 13:28
@Natsukingdom Natsukingdom marked this pull request as ready for review March 2, 2026 13:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant