What problem does this solve?
Several SDK-backed resolvers need GraphQL operations before they can move to GraphQLClient without behavior loss. Some coverage already exists, but a few resolver-specific lookups are missing filter variables or fields.
Proposed solution
Add or extend narrowly scoped GraphQL lookup operations for resolver migration.
Needed coverage:
- team lookup by id/key/name with estimation fields
- project lookup by case-insensitive name with
includeArchived
- project label lookup by case-insensitive name
- workflow state lookup by name and optional team
- initiative lookup using a dynamically supplied
InitiativeFilter
Potential files:
graphql/queries/teams.graphqlgraphql/queries/projects.graphqlgraphql/queries/labels.graphqlgraphql/queries/issues.graphqlgraphql/queries/initiatives.graphql
Run npm run generate after editing GraphQL documents.
Alternatives considered
- Reuse broad list queries and filter client-side: simpler but less efficient and less precise for duplicate handling.
- Use existing
FindInitiativesByName directly: risky because nullable scope variables may not match the current dynamic SDK filter behavior.
Primary use case
Shell scripting / automation
Additional context
Important parity requirements:
resolveTeamId() must preserve key-first, then name lookup order.resolveProjectId(..., { includeArchived }) must preserve archive-aware lookup behavior.resolveProjectId() must continue throwing on multiple name matches.resolveStatusId() currently returns the first matching status when unscoped; do not introduce ambiguity errors unless intentionally scoped separately.resolveLabelId() currently returns the first matching label; preserve that behavior.
Acceptance criteria:
- New/updated GraphQL operations are generated into
src/gql/ via npm run generate.
- No manual edits are made under
src/gql/.
- Generated types are sufficient to remove
LinearDocument.* SDK filter imports later.
What problem does this solve?
Several SDK-backed resolvers need GraphQL operations before they can move to
GraphQLClientwithout behavior loss. Some coverage already exists, but a few resolver-specific lookups are missing filter variables or fields.Proposed solution
Add or extend narrowly scoped GraphQL lookup operations for resolver migration.
Needed coverage:
includeArchivedInitiativeFilterPotential files:
graphql/queries/teams.graphqlgraphql/queries/projects.graphqlgraphql/queries/labels.graphqlgraphql/queries/issues.graphqlgraphql/queries/initiatives.graphqlRun
npm run generateafter editing GraphQL documents.Alternatives considered
FindInitiativesByNamedirectly: risky because nullable scope variables may not match the current dynamic SDK filter behavior.Primary use case
Shell scripting / automation
Additional context
Important parity requirements:
resolveTeamId()must preserve key-first, then name lookup order.resolveProjectId(..., { includeArchived })must preserve archive-aware lookup behavior.resolveProjectId()must continue throwing on multiple name matches.resolveStatusId()currently returns the first matching status when unscoped; do not introduce ambiguity errors unless intentionally scoped separately.resolveLabelId()currently returns the first matching label; preserve that behavior.Acceptance criteria:
src/gql/vianpm run generate.src/gql/.LinearDocument.*SDK filter imports later.