main is red again, from my own #322. This fixes it, and closes the gap that let it through.
The failure
errorHandling.integration.test.ts does not typecheck:
TS2345: Argument of type 'Error' is not assignable to parameter of type 'never'.
jest.spyOn(pool, 'query').mockRejectedValueOnce(new Error(DB_FAILURE));
pg declares query with several overloads. jest.spyOn resolves the mock's argument against the last of them, whose parameter list is empty — so the inferred type for a rejection value is never, and nothing can be assigned to it.
ts-jest compiles each suite as it runs, so this surfaced as a suite that failed to run rather than a test that failed. That is why run 889 reported 446 passed, 0 failed and the step red anyway — the summary line looked healthy while a whole file never executed.
The as never cast is the type system rather than a shortcut, and the file says so: every overload rejects on failure, and the cast only chooses which one to check against.
Why it reached main, which matters more than the fix
The backend has a tsconfig.test.json covering scripts and tests, and nothing was running it.build compiles src alone. I had been reporting "tsc clean" on that basis while editing test files it never looked at.
The frontend's build has run its equivalent all along (tsc && tsc -p tsconfig.test.json --noEmit && vite build), so the gap was one workspace wide and invisible from the other.
It is now a script:
npm run typecheck:tests
It reproduces this failure in seconds, against no database.
That matters beyond this one fix. The standing explanation for integration regressions here has been that the suite needs Postgres and a Node this machine cannot run — which is true of the tests, but was never true of a type error in a test. That only looked unreachable because the check that finds it was never invoked. Two of the three integration regressions today were this class.
Not added to build. The Dockerfile runs that, and a production image should not fail to build because a test file has a type error.
Verification
typecheck:tests clean · build tsc clean · lint 0 errors, no new warnings · 485 unit tests passing.
The suite itself still needs CI to run — but it will now at least compile, which is the thing that was wrong.
**`main` is red again, from my own #322.** This fixes it, and closes the gap that let it through.
## The failure
`errorHandling.integration.test.ts` does not typecheck:
```
TS2345: Argument of type 'Error' is not assignable to parameter of type 'never'.
jest.spyOn(pool, 'query').mockRejectedValueOnce(new Error(DB_FAILURE));
```
`pg` declares `query` with several overloads. `jest.spyOn` resolves the mock's argument against the last of them, whose parameter list is empty — so the inferred type for a rejection value is `never`, and nothing can be assigned to it.
ts-jest compiles each suite as it runs, so this surfaced as a **suite that failed to run** rather than a test that failed. That is why [run 889](https://gitea.bermudalamb.synology.me/bermudalamb/redefined-designs/actions/runs/889) reported `446 passed, 0 failed` and the step red anyway — the summary line looked healthy while a whole file never executed.
The `as never` cast is the type system rather than a shortcut, and the file says so: every overload rejects on failure, and the cast only chooses which one to check against.
## Why it reached main, which matters more than the fix
**The backend has a `tsconfig.test.json` covering `scripts` and `tests`, and nothing was running it.** `build` compiles `src` alone. I had been reporting "tsc clean" on that basis while editing test files it never looked at.
The frontend's build has run its equivalent all along (`tsc && tsc -p tsconfig.test.json --noEmit && vite build`), so the gap was one workspace wide and invisible from the other.
It is now a script:
```
npm run typecheck:tests
```
It reproduces this failure **in seconds, against no database.**
That matters beyond this one fix. The standing explanation for integration regressions here has been that the suite needs Postgres and a Node this machine cannot run — which is true of the *tests*, but was never true of a **type error in a test**. That only looked unreachable because the check that finds it was never invoked. Two of the three integration regressions today were this class.
**Not added to `build`.** The Dockerfile runs that, and a production image should not fail to build because a test file has a type error.
## Verification
`typecheck:tests` clean · `build` tsc clean · lint 0 errors, no new warnings · **485 unit tests passing**.
The suite itself still needs CI to run — but it will now at least compile, which is the thing that was wrong.
Refs #307
🤖 Generated with [Claude Code](https://claude.com/claude-code)
The trigger added in #322 does not typecheck. pg declares query with several overloads and jest.spyOn resolves the mock argument against the last of them, whose parameter list is empty, so the inferred type of a rejection value is never and an Error cannot be assigned to it. ts-jest compiles each suite as it runs, so this surfaced as a suite that failed to run rather than as a test that failed — which is why CI reported 446 tests passing, zero failing, and the step red anyway.
The cast is the type system rather than a shortcut, and says so in the file: every overload rejects on failure, and the cast only chooses which one to check against.
The reason this reached main is the part worth keeping. The backend has a tsconfig.test.json covering scripts and tests, and nothing was running it — build compiles src alone, and I had been reporting tsc clean on that basis while touching test files it never looked at. The frontend build has run its equivalent all along, so the gap was one workspace wide and invisible from the other.
It is now a script, typecheck:tests, and it reproduces this failure in seconds against no database. That matters beyond this fix: the standing excuse for integration regressions here has been that the suite needs Postgres and a Node this machine cannot run, and a type error in a test was never actually in that category — it only looked like it because the check that finds it was never invoked.
Not added to build. The Dockerfile runs that, and a production image should not fail to build because a test file has a type error.
Verified: typecheck:tests clean, build tsc clean, lint 0 errors with no new warnings, 485 unit tests passing. The suite itself still needs CI to run.
Refs #307
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
mainis red again, from my own #322. This fixes it, and closes the gap that let it through.The failure
errorHandling.integration.test.tsdoes not typecheck:pgdeclaresquerywith several overloads.jest.spyOnresolves the mock's argument against the last of them, whose parameter list is empty — so the inferred type for a rejection value isnever, and nothing can be assigned to it.ts-jest compiles each suite as it runs, so this surfaced as a suite that failed to run rather than a test that failed. That is why run 889 reported
446 passed, 0 failedand the step red anyway — the summary line looked healthy while a whole file never executed.The
as nevercast is the type system rather than a shortcut, and the file says so: every overload rejects on failure, and the cast only chooses which one to check against.Why it reached main, which matters more than the fix
The backend has a
tsconfig.test.jsoncoveringscriptsandtests, and nothing was running it.buildcompilessrcalone. I had been reporting "tsc clean" on that basis while editing test files it never looked at.The frontend's build has run its equivalent all along (
tsc && tsc -p tsconfig.test.json --noEmit && vite build), so the gap was one workspace wide and invisible from the other.It is now a script:
It reproduces this failure in seconds, against no database.
That matters beyond this one fix. The standing explanation for integration regressions here has been that the suite needs Postgres and a Node this machine cannot run — which is true of the tests, but was never true of a type error in a test. That only looked unreachable because the check that finds it was never invoked. Two of the three integration regressions today were this class.
Not added to
build. The Dockerfile runs that, and a production image should not fail to build because a test file has a type error.Verification
typecheck:testsclean ·buildtsc clean · lint 0 errors, no new warnings · 485 unit tests passing.The suite itself still needs CI to run — but it will now at least compile, which is the thing that was wrong.
Refs #307
🤖 Generated with Claude Code