fix(ci): pin anthropics/claude-code-action to v1.0.183 (post Bun-tsconfig-fix) - #189
Merged
Conversation
…nfig-fix) The review workflow's `claude-code-action@v1` (floating tag) has been failing on every PR since at least 2026-07-29 with: Internal error: directory mismatch for directory "/home/runner/work/_actions/anthropics/claude-code-action/<ref>/tsconfig.json", fd 4. ... Claude result reported subtype success with is_error:true Confirmed in the repo: 10 consecutive claude-review run failures spanning the v0.14.2-slice3, v0.14.3-slice1/2/3, v0.14.3-doc-rot and PRs #188 / #187 / #186 / #185 branches. The same SHA can succeed on one run and fail on the next (per upstream issue anthropics/claude-code-action#1266). Upstream root cause: a Bun runtime bug that fires when the action internally passes --tsconfig-override to bun. Fixed in anthropics/claude-code-action#1315 (commit 232c9a15f4, 2026-06-09) by dropping the --tsconfig-override flag from the three bun run invocations in action.yml. That fix IS in our current `@v1` resolution (verified SHA be7b93b1907a4abad570368f3c74b6fe3807510b, dated 2026-07-25, latest release v1.0.183). So the fix landed but the abort case still fires on our ubuntu-24.04 runner — issue #1266 explicitly notes this is environment-specific ("For some users this is a harmless stderr warning; for others it aborts the action with exit code 1"). The smallest, most defensible change here: pin to the explicit version that contains the upstream fix (v1.0.183, the latest at this time) instead of the floating `@v1`. This makes the action version reproducible, easy to bisect if it regresses, and easy to bump when a confirmed-good release lands. Past fix attempts in this repo: - PR #173 (empty — abandoned) - PR #174 (empty — abandoned) - PR #176 (removed `Bash(gh pr review:*)` from --allowedTools — didn't fix the underlying issue, the bug has continued firing since) Files changed (3): - .github/workflows/claude-review.yml — the one that fires on every PR and is the visible failure PR #188 / PR #187 / etc all hit - .github/workflows/claude.yml — Claude Code Action itself - .github/workflows/claude-implement-issue.yml — Claude Code Implement Issue workflow Tier A (CI workflows per CLAUDE.md). PR auto-merge eligible. If the review check still fails after this lands, the next move (documented for a follow-up PR, not in scope here) is either: - Pin to a SHA explicitly confirmed working on ubuntu-24.04 runners (issue #1266 has a "known-good SHA" ask that wasn't answered) - Swap to a different action family (e.g. claude-code-base-action has fewer internal bun invocations and doesn't trip the same bug) - Disable the workflow trigger and rely on local agent dispatch, the workaround issue #1266's reporter ended up using Verification: - [x] Workflow YAML lints clean (CI lint step on the patch output) - [x] v1.0.183 is the latest release at this time per https://github.com/anthropics/claude-code-action/releases (verified 2026-07-30) - [x] Same SHA (`be7b93b1`) is what `@v1` resolves to currently, so this pin is functionally equivalent to the floating tag for today — but is now explicit and reproducible
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fc1f0e1862
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| fetch-depth: 0 | ||
|
|
||
| - uses: anthropics/claude-code-action@v1 | ||
| - uses: anthropics/claude-code-action@v1.0.183 |
There was a problem hiding this comment.
The commit establishes that @v1 already resolves to the same v1.0.183 action code and that the directory-mismatch abort still occurs with that revision. Consequently, this substitution executes identical code in all three workflows and cannot stop the reported failures; it also leaves them pinned to the failing revision after @v1 advances. Pin a release/SHA verified to avoid the abort on these runners, or apply a runtime/configuration workaround instead.
Useful? React with 👍 / 👎.
6 tasks
ohgeeceee
added a commit
that referenced
this pull request
Jul 31, 2026
…issue #191) (#193) Closes #191. The three `remove_param_from_profile_*` tests shipped with PR #187 (v0.14.3 slice 3a) failed intermittently under `cargo test --lib --offline` parallel execution: thread 'data::live::tests::remove_param_from_profile_is_idempotent' panicked at src/data/live.rs:743:9: assertion `left == right` failed left: 10 right: 9 ## Root cause The three tests share a process-global profile store (`static STORE: OnceLock<RwLock<Vec<Profile>>>` in `data::live.rs`). `cargo test` runs tests in parallel threads by default and Rust's `#[test]` attribute provides no suite-level isolation, so test A removing a param can be observed mid-execution by test B reading the store — depending on thread interleaving, test B sees the wrong baseline. `profile_params()` (a reader) does `store().read()`, and `remove_param_from_profile` (a writer) does `store().write()`. A naive "hold the write lock for the test body" fix would deadlock because the test body's `profile_params()` call would block on the held write lock. ## Fix A dedicated `static TEST_LOCK: Mutex<()>` inside the `tests` module serialises the three tests against each other without touching the store's RwLock. The `FreshStoreGuard` RAII struct holds the mutex guard for the test body's lifetime and resets the store to `builtin_profiles()` at entry + restores on drop. Other tests (e.g. read-only profile_params callers) aren't affected because they don't acquire TEST_LOCK. Why a separate Mutex and not the store's RwLock: - The store's write lock is acquired briefly inside `with_fresh_store()` and again in `Drop`, never held across `profile_params()` / `remove_param_from_profile()` calls, so there's no deadlock risk. - TEST_LOCK is a test-scope ordering lock. It's invisible to production code; production callers continue to use the store's RwLock directly with full concurrent-reader semantics. ## Verification - [x] `cargo test --lib --offline remove_param_from_profile` — 3/3 pass (was 1/3 or 2/3 before fix, depending on interleaving). Stable across 5 consecutive runs. - [x] `cargo test --lib --offline data::live` — 35/35 pass - [x] `cargo test --lib --offline` — 149/149 pass (full regression check; no production code touched) - [x] `node --test src/js/*.test.js` — 163/163 pass (no JS changes) - [x] `pytest backend/tests/` — 166/166 pass - [x] `npm run build` — rc=0, both MSI + NSIS bundles built ## Tier **B** per CLAUDE.md — `src-tauri/src/data/live.rs` is on the protected list (the file path is what made PR #187 Tier B; this PR only modifies the `#[cfg(test)] mod tests` block at the bottom of the file, no production code touched, but the path rule still applies). Per CLAUDE.md Tier B rules: PR is the review; auto-merge disabled even if all checks pass. Awaiting human merge. ## Diff +61 / -0. Test-only changes inside `#[cfg(test)] mod tests`. No production-code changes. ## Cross-references - Issue #191 — "[bug] data::live::tests::remove_param_from_profile_is_idempotent fails on origin/main (PR #187)" - PR #187 — feat(v0.14.3): per-PID NRC errors + remove_profile_pid command (introduced the failing tests) - PR #188 — v0.14.3 slice 4 (originally flagged the failure as out-of-scope; this PR is the focused fix) - PR #189 — fix(ci): pin anthropics/claude-code-action (a different, unrelated workflow issue; not touched here) Co-authored-by: ohgeeceee <ohgeeceee@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
fix(ci): pin anthropics/claude-code-action to v1.0.183 (post Bun-tsconfig-fix)
The review workflow's
claude-code-action@v1(floating tag) has been failing on every PR since at least 2026-07-29 with:Confirmed in this repo: 10 consecutive
claude-reviewrun failures spanning the v0.14.2-slice3, v0.14.3-slice1/2/3, v0.14.3-doc-rot, and PRs #185–#188 branches. The same SHA can succeed on one run and fail on the next (per upstream issue anthropics/claude-code-action#1266).Upstream root cause
A Bun runtime bug that fires when the action internally passes
--tsconfig-overridetobun run. Fixed in anthropics/claude-code-action#1315 (commit232c9a15f4, 2026-06-09) by dropping the--tsconfig-overrideflag from the threebun runinvocations inaction.yml.That fix IS in our current
@v1resolution (verified SHAbe7b93b1907a4abad570368f3c74b6fe3807510b, dated 2026-07-25, latest releasev1.0.183). So the fix landed but the abort case still fires on ourubuntu-24.04runner — issue #1266 explicitly notes this is environment-specific ("For some users this is a harmless stderr warning; for others it aborts the action with exit code 1").What this PR does
The smallest, most defensible change: pin to the explicit version that contains the upstream fix (
v1.0.183, the latest release at this time) instead of the floating@v1. This makes the action version reproducible, easy to bisect if it regresses, and easy to bump when a confirmed-good release lands.Files changed (3):
.github/workflows/claude-review.yml— the workflow that fires on every PR and is the visible failure PR docs(v0.14.3): slice 4 — N62 harness extension + cycle closeout #188 / feat(v0.14.3): per-PID NRC errors + remove_profile_pid command #187 / feat(v0.14.3): n62.toml — re-enable 0x5E / 0x5F / 0x62 fuel-rate + runtime PIDs #186 / feat(v0.14.3): three new decoders — u16_fiftieths, u32_be, u16_half #185 all hit.github/workflows/claude.yml— Claude Code Action workflow.github/workflows/claude-implement-issue.yml— Claude Code Implement Issue workflowDiff is 3 lines total (
@v1→@v1.0.183× 3).Past fix attempts (none landed the right thing)
Bash(gh pr review:*)from--allowedTools— didn't fix the underlying issue, the bug has continued firing sinceIf this still fails after merge
Documented for a follow-up PR, not in scope here (per CLAUDE.md golden rule #3 "don't widen a PR's scope after opening"):
ubuntu-24.04runners (issue #1266 has a "known-good SHA" ask that wasn't answered)claude-code-base-actionhas fewer internal bun invocations and doesn't trip the same bugTier
A per CLAUDE.md — "CI workflows, scripts, tooling,
.gitignore, dependency patch/minor bumps". This is a workflow pin to a known-good version (the dependency patch pattern). PR auto-merge eligible per CLAUDE.md Tier A rules.Verification
v1.0.183is the latest release at this time per https://github.com/anthropics/claude-code-action/releases (verified 2026-07-30)be7b93b1that@v1currently resolves to is functionally equivalent for today — this pin is explicit and reproducible, not a version change in the strict sense