fix(ci): fix mutated workfile

[wochinge]

Summary

• Upgrade CI workflow from Node 20 to Node 24 to match the release workflow
• Add lockfile integrity check to CI lint job to catch mismatches early
• Reverts the standalone: true workaround from 5e3dc09
• Revert GitHub action that already uses pnpm 11

Test plan

• CI passes with Node 24
• Trigger release workflow dry run to verify lockfile integrity check passes

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
langfuse-js	Ready	Preview	Apr 17, 2026 2:07pm

[github-actions]

@claude review

[claude]

LGTM — simple CI alignment fixing the root cause rather than working around it.

Extended reasoning...

Overview

Single-file change to .github/workflows/release.yml: downgrades Node from 24 to 20 to match the CI workflow, and removes the standalone: true workaround on pnpm/action-setup that was added as a temporary fix in 5e3dc09.

Security risks

None. This is a CI configuration change only — it adjusts the Node version and removes a non-default pnpm flag. No secrets, auth, or runtime code is touched.

Level of scrutiny

Low. The change is two-line deletions and a one-line version bump in a workflow file. The root cause (Node 24 causing pnpm to mutate the lockfile) is well-understood and the fix is the canonical solution.

Other factors

No bugs were reported. The diff is minimal and the PR description clearly explains both the problem and the rationale. The workaround being reverted was itself a direct-to-main commit, so cleaning it up via a PR is appropriate.

[claude]

LGTM — straightforward CI upgrade from Node 20 to 24, lockfile update from pnpm 10.33, and revert of the standalone workaround.

Extended reasoning...

Overview

Changes touch only CI workflow files (, ) and the auto-generated . No application or library code is modified.

Security Risks

None. The lockfile additions are pnpm's own platform-specific binary entries auto-written by pnpm 10.33 on Node 24. The new lockfile integrity check is a positive defensive addition, not a risk.

Level of Scrutiny

Low. These are mechanical CI config changes: version number bumps (20 → 24), auto-generated lockfile metadata, removal of a now-unnecessary workaround (), and a helpful integrity guard. All changes are consistent with the described intent.

Other Factors

No bugs found. No outstanding reviewer comments. The changes align with the existing release workflow (which already used Node 24) and the commit history context (5e3dc09 added the standalone workaround to fix a lockfile issue; this PR resolves the root cause and reverts it).

[claude]

LGTM — straightforward CI maintenance upgrading Node 20→24 and pinning pnpm 10; the inline nit about consistency in the test jobs is worth addressing but doesn't block this.

Extended reasoning...

Overview

Touches only and . Changes: upgrade Node 20→24 across all CI jobs, pin pnpm to v10 (replacing the prior workaround), add + git-diff integrity check to the lint job, and align release.yml to the same pnpm pinning approach.

Security risks

None. This is a CI config change with no production code, secrets handling, auth logic, or permission model changes. The pnpm pinning actually improves supply-chain hygiene by preventing an upstream action from silently upgrading to pnpm v11.

Level of scrutiny

Low. The changes are mechanical and follow well-understood patterns. Node 24 is an LTS candidate and is already in use in the release workflow, so the upgrade is an alignment fix rather than a risky jump. The pnpm v10 pin has a clear upstream reference (#228 on pnpm/action-setup). The lockfile integrity check in lint is additive and conservative.

Other factors

The one nit flagged by the bug hunter — missing on the and jobs — is real but minor. The gate requires lint to pass before anything merges, so a stale lockfile will still be caught before merge; the only cost of the inconsistency is potentially wasted test-job runs. This doesn't warrant blocking the PR, but it would be a clean follow-up to add the flag there too.

---

Additional findings (outside current diff — PR may have been updated during review):

• 🟡 .github/workflows/ci.yml:37-38 — The test-integration and test-e2e jobs use plain pnpm install while the lint job (added in this PR) uses pnpm install --frozen-lockfile with an integrity check, creating inconsistent lockfile enforcement across CI. If a PR has a stale pnpm-lock.yaml, both test jobs could silently install different dependency versions and produce misleading pass/fail signals before lint catches the mismatch, wasting CI resources and potentially confusing developers. Adding --frozen-lockfile to both test jobs would make enforcement consistent.

  Extended reasoning...

  What the bug is: This PR introduced --frozen-lockfile and a lockfile integrity check to the lint job, but the same flag was not applied to the test-integration or test-e2e jobs. These two jobs still use plain pnpm install, which allows pnpm to silently update package resolutions in memory when the lockfile is stale.

  The specific code path: In .github/workflows/ci.yml, the test-integration job (line 37) runs pnpm install and the test-e2e job runs pnpm install (around line 101). The lint job at line 171 was updated in this PR to use pnpm install --frozen-lockfile followed by a git diff --exit-code pnpm-lock.yaml integrity check. All three jobs run in parallel via the all-tests-passed aggregator.

  Why existing code does not prevent it: The pnpm v10 pin prevents the lockfile file on disk from being mutated, but without --frozen-lockfile, pnpm can still perform in-memory resolution with different package versions when the committed lockfile is stale (i.e., when package.json has changed without updating pnpm-lock.yaml). The lint check fires after the test jobs have already started their installs.

  Concrete step-by-step proof: 1) A developer adds a new dependency to package.json but forgets to run pnpm install to update the lockfile. 2) They open a PR with the stale pnpm-lock.yaml. 3) All three CI jobs start in parallel. 4) test-integration and test-e2e run pnpm install — pnpm resolves the new dependency to its latest available version and installs with those resolved versions in memory. 5) Tests run against this unintended set of dependency versions. 6) Meanwhile, lint runs pnpm install --frozen-lockfile, which fails immediately because the lockfile does not match package.json. 7) The developer sees test results (pass or fail) that were produced against dependency versions not reflected in the committed lockfile, potentially misleading them about whether their code is correct.

  Impact: No production code is affected, and the all-tests-passed gate blocks merging when lint fails. However, CI resources are wasted on test runs against unintended dependency versions, and test signals could be confusing — tests failing on a bad dep version may look like a code bug, or tests passing give false confidence.

  Fix: Add --frozen-lockfile to both pnpm install steps in test-integration and test-e2e, mirroring the lint job.

[claude]

LGTM — clean CI-only change with well-reasoned pnpm v5 pin and lockfile integrity checks.

Extended reasoning...

Overview

This PR touches only .github/workflows/ci.yml and .github/workflows/release.yml. It upgrades Node from 20 to 24, downgrades pnpm/action-setup from v6 to v5 (to avoid pnpm v11 lockfile mutations per a known upstream issue), adds --frozen-lockfile + git diff integrity checks to the lint and release jobs, and removes the standalone: true workaround added in the previous commit.

Security risks

The only security-adjacent concern is action SHA pinning — both CI files now consistently use b307475762933b98ed359c036b0e51f26b63b74b labeled # v5.0.0. The diff shows a different SHA (fc06bc1) because the author amended the PR after opening; the current committed state is internally consistent across all four action usages. A nit about verifying the SHA-to-tag mapping has been flagged inline. No auth, crypto, or production code is affected.

Level of scrutiny

Low — this is entirely CI infrastructure. There are no changes to SDK source code, tests, or published artifacts. The logic is straightforward and follows patterns already established in the release workflow (which also uses --frozen-lockfile + lockfile integrity check). The Node 24 upgrade aligns CI with the release workflow.

Other factors

Both flagged bugs are labeled as nits by the bug hunter and are already attached as inline comments. The asymmetry in --frozen-lockfile usage (lint enforces it, test jobs don't) is a reasonable incremental improvement rather than a blocker. No outstanding human reviewer comments exist.

[claude]

🟡 The lint job now uses pnpm install --frozen-lockfile (added in this PR), but test-integration and test-e2e still use plain pnpm install, creating an asymmetry. If a developer pushes a PR with a stale lockfile, the test jobs will silently auto-resolve and potentially pass with different dependency versions, while lint fails — making the failure appear to be a lint configuration problem rather than a lockfile mismatch.

Extended reasoning...

This PR introduced an asymmetry in how CI jobs handle lockfile integrity. The lint job now explicitly enforces --frozen-lockfile and even adds a subsequent git diff --exit-code pnpm-lock.yaml integrity check. However, the test-integration (line 35) and test-e2e (around line 92) jobs still use plain pnpm install.

The specific code paths are:

• test-integration (ci.yml:35): - run: pnpm install
• test-e2e (ci.yml, after docker setup): - run: pnpm install
• lint (ci.yml:166): - run: pnpm install --frozen-lockfile

Why the existing code doesn't prevent the issue: Plain pnpm install on pnpm v5/v10 will silently update metadata fields (such as packageManagerDependencies added by pnpm 10.33 on Node 24) in the in-memory lockfile and proceed successfully — it does not error on a stale lockfile.

The impact: When a developer pushes a PR where the lockfile is slightly stale (e.g., the committed lockfile is missing the packageManagerDependencies section written by pnpm 10.33 on Node 24), the following sequence occurs: (1) test-integration runs, silently resolves deps with an updated lockfile, tests pass; (2) test-e2e runs, same silent resolution, tests pass; (3) lint runs, --frozen-lockfile rejects the stale lockfile and the job fails. The developer sees "tests passed, lint failed" and investigates lint configuration, ESLint rules, or formatting — not realizing the root cause is a lockfile mismatch. This is particularly confusing given the PR's explicit intent is to enforce lockfile integrity.

How to fix: Add --frozen-lockfile to both pnpm install steps in test-integration and test-e2e, matching the lint job:

- run: pnpm install --frozen-lockfile

Step-by-step proof:

1. Developer updates a dependency in package.json but forgets to run pnpm install to regenerate pnpm-lock.yaml.
2. PR is pushed. CI starts all three jobs in parallel.
3. test-integration: runs pnpm install (no --frozen-lockfile), pnpm resolves the updated dep and generates a new in-memory lockfile. Tests run and pass.
4. test-e2e: same as above, tests run and pass.
5. lint: runs pnpm install --frozen-lockfile, pnpm detects the lockfile is out of sync with package.json, and fails immediately with an error about the frozen lockfile.
6. CI result: 2/3 jobs pass, lint fails. Developer opens lint logs expecting a code style issue, finds a pnpm lockfile error — confusing, since tests already "passed" with the auto-resolved deps.

[claude]

🟡 The PR diff shows pnpm/action-setup pinned to fc06bc1257f339d1d5d8b3a19a8cae5388b55320 (labeled # v5.0.0), but the actual committed files all use b307475762933b98ed359c036b0e51f26b63b74b (also labeled # v5.0.0). Since a git tag points to exactly one commit, only one of these SHAs can be the real v5.0.0 release — please verify that b307475 is truly the v5.0.0 commit for pnpm/action-setup, as using a misidentified SHA undermines the security guarantee of action pinning.

Extended reasoning...

What the discrepancy is: The PR diff (captured at PR-open time) shows pnpm/action-setup@fc06bc1257f339d1d5d8b3a19a8cae5388b55320 # v5.0.0, while every copy of the action in the merged files — three occurrences in ci.yml and one in release.yml — uses b307475762933b98ed359c036b0e51f26b63b74b # v5.0.0. Both are labeled as the same version tag, but they are different commits.

Most likely explanation: The author pushed an additional commit (or force-pushed) after the initial PR was opened, switching from fc06bc1 to b307475. The current repository state is internally consistent — all four usages agree on b307475 — so this is not a split-brain problem in the merged code. The refutation argument (that this is just normal PR amendment) is plausible.

Why it still warrants verification: A git tag (e.g., v5.0.0) resolves to exactly one commit SHA. If b307475 is the floating v5 branch tip or an unrelated commit rather than the immutable v5.0.0 tag commit, then the comment is wrong — and the supposed security benefit of SHA-pinning (reproducibility, tamper-evidence) is lost. The entire reason to pin to a SHA instead of using pnpm/action-setup@v5 is to lock to a known-good, immutable point.

Concrete proof of the issue: Running git ls-remote https://github.com/pnpm/action-setup refs/tags/v5.0.0 would reveal the canonical commit for that tag. If that output does not match b307475762933b98ed359c036b0e51f26b63b74b, then the label is wrong and CI is running an unverified version of the action. Even if the SHA happens to be safe today, a mislabeled pin provides false confidence.

How to fix: Verify the correct v5.0.0 SHA via git ls-remote https://github.com/pnpm/action-setup refs/tags/v5.0.0 and update all four workflow usages to the confirmed SHA (or update the comment label if the SHA is intentionally a different v5.x commit). All four locations should be updated together to remain consistent.