Job `environment` validation only sees the first 30 repository environments

Open Beginner friendly
#392 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
86/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
github, typescript
Domain
devtools

Research direction

Start in languageserver/src/value-providers/job-environment.ts at lines 15-18 and inspect the repository-environment fetch. Use the supplied 35-environment reproduction to verify that environments beyond the API's default 30 are seen, and confirm the diagnostic no longer flags a valid later environment.

Written by the indexing model from the issue text.

Description

Describe the bug

The job environment value provider fetches the repository's environments with a single repos.getAllEnvironments({owner, repo}) call and no per_page or pagination, so it receives the API default of 30. In a repository with more than 30 environments, any job whose environment sorts past the 30th in the API's order is reported as Value '<name>' is not valid (severity Error), even though the environment exists and the workflow deploys to it.

Fetch: https://github.com/actions/languageservices/blob/4043eda158e16579cc5fb1b0b07a4bce2a76f0b5/languageserver/src/value-providers/job-environment.ts#L15-L18

Diagnostic: https://github.com/actions/languageservices/blob/4043eda158e16579cc5fb1b0b07a4bce2a76f0b5/languageservice/src/validate.ts#L259-L266

To Reproduce

Steps to reproduce the behavior:

  1. In a repository with 35 environments, list them all with gh api 'repos/OWNER/REPO/environments?per_page=100' --jq '.environments[].name'. The same call without per_page returns only the first 30 of those names, so the last five in the full list are the ones the language server never sees.
  2. Open a workflow with a job that uses one of those five, for example:
jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production-approval
    steps:
      - run: echo deploy
  1. See Value 'production-approval' is not valid on the environment line. Jobs that use any of the first 30 environments show no diagnostic.

Expected behavior

Every environment the repository defines is accepted. The Octokit method takes per_page (max 100), and client.paginate(client.repos.getAllEnvironments, {owner, repo, per_page: 100}) returns the full list, since @octokit/plugin-paginate-rest normalizes responses wrapped in total_count.

Screenshots

Not needed; the reproduction above is deterministic.

Package/Area

  • Expressions
  • Workflow Parser
  • Language Service
  • Language Server

Package Version

@actions/languageserver 0.3.61, as bundled by the VS Code GitHub Actions extension 0.32.3.

Additional context

  • github/vscode-github-actions#278 (open) reports the same 30-environment limit for the extension's Settings tree view and notes that it also breaks validation. The open fix github/vscode-github-actions#476 paginates only the tree view (src/treeViews/settings/environmentsNode.ts); the validation path is this package's value provider, so that PR does not resolve the diagnostic.
  • github/vscode-github-actions#402 and #377 here are different environment false positives (an environment that does not exist yet, and a reusable workflow whose caller owns the environment), not truncation.

Drafted by Claude (Anthropic AI assistant).

Dominant language
TypeScript
Stars
193
Forks
74
PR merge metrics
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from actions/languageservices

All issues in actions/languageservices

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.