fix(core): retry a lazy ORM import in lower.ts after a rejection by borisno2 · Pull Request #1286 · OpenSaasAU/stack

borisno2 · 2026-09-07T11:23:44Z

Summary

packages/core/src/secured/lower.ts loads Prisma's and/or/all combinators (whereCombinators) and the pgvector expression builders (vectorLowering) through a lazy import(), caching the resulting promise in a module-level variable so the package root's static import graph stays free of @prisma/orm-postgres.

Both cached the promise even when it rejected. A single transient import failure was therefore permanent for the life of the process: every later call re-awaited the same rejected promise, and every secured read (and any .nearest() vector search) would fail until the process restarted, with no way to recover.

whereCombinators was the specific case flagged in A rejected lazy ORM import in lower.ts is cached permanently, poisoning the process #1231 (deliberately left unfixed in The Where vocabulary and its lowering; the filter module retyped #1220, which was scoped to the blocking findings).
vectorLowering has the exact same caching pattern in the same file, so I fixed it too rather than leave an identical latent bug sitting next to the one just fixed.

What changed

Both functions now clear their module-level cache in a .catch() before rethrowing, so:

A rejected import is not cached — the next call retries.
A successful import is still cached — no per-call import cost, no race (the ??= guard is unchanged).

vectorLowering's inline .then() callback was extracted into a small loadVectorLowering() async function — chaining .catch() directly after the original inline .then() broke TypeScript's contextual typing for the order/bound closures (their parameter types are inferred from the VectorLowering interface via the Promise<VectorLowering> assignment target, which chaining .catch() onto the same expression disrupted). No behavioral change beyond the fix itself.

Test plan

New packages/core/src/secured/lower.test.ts: for both whereCombinators and vectorLowering, mocks the lazy import to throw once, asserts the call rejects, then un-mocks it and asserts the next call succeeds — proving the retry. A separate test proves a successful import is still cached (one factory call across repeated callers).
pnpm build (tsc) — clean
pnpm test — 85 files, 1663 passed / 2 skipped (core package)
pnpm lint — 0 errors (2 pre-existing warnings, both untouched by this change)
pnpm manypkg fix and pnpm format — no changes needed
Changeset added (@opensaas/stack-core: patch)

Closes #1231

🤖 Generated with Claude Code

https://claude.ai/code/session_01HWS4RTvCjP7p5J2LrjNUMR

Generated by Claude Code

whereCombinators and vectorLowering cached the promise from a lazy import() even when it rejected, so a single transient import failure was permanent for the life of the process. A rejection now clears the cache so the next call retries; a successful import is still cached. Closes #1231 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HWS4RTvCjP7p5J2LrjNUMR

vercel · 2026-09-07T11:23:48Z

Deployment failed for project stack-docs with the following error:

Resource is limited - try again in 24 hours (more than 100, code: "api-deployments-free-per-day").

Learn More: https://vercel.com/open-saas?upgradeToPro=build-rate-limit

chatgpt-codex-connector · 2026-09-07T11:23:49Z

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

changeset-bot · 2026-09-07T11:23:54Z

🦋 Changeset detected

Latest commit: 7bdab21

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 9 packages

Name	Type
@opensaas/stack-core	Patch
@opensaas/stack-auth	Patch
@opensaas/stack-cli	Patch
@opensaas/stack-rag	Patch
@opensaas/stack-storage	Patch
@opensaas/stack-tiptap	Patch
@opensaas/stack-ui	Patch
@opensaas/stack-storage-s3	Patch
@opensaas/stack-storage-vercel	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

borisno2

Single-pass review at high effort (Agent tool unavailable in this context — no multi-agent fan-out or subagent verify pass ran; I worked all 8 angles myself in one context). This is a small, tightly-scoped fix (69 lines in lower.ts, +68 new test lines). I traced the ??= + synchronous-catch-handler reset logic by hand for races and found none — the mutual exclusion via pending/pendingVector staying truthy while a promise is in flight rules out two generations of the cache ever being confused. No callers depend on the old permanent-cache-on-rejection behavior. No correctness bugs found; the two comments below are low-severity cleanup/docs notes only.

Generated by Claude Code

… cache whereCombinators and vectorLowering duplicated the identical cache-unless-rejected pattern; centralizing it in one lazyImport<T> helper means the race-sensitive logic only needs to be correct once, and moving vectorLowering's loader inline restores its "Known limits" TSDoc onto the exported symbol (it had drifted onto an unexported helper when the previous commit split it out for type inference). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HWS4RTvCjP7p5J2LrjNUMR

borisno2 · 2026-09-07T11:31:28Z

The Vercel status check is red on this PR, but it's not this PR's failure: it's a stack-docs deployment hitting Vercel's free-tier daily quota (Resource is limited - try again in 24 hours (more than 100, code: "api-deployments-free-per-day")), unrelated to anything this diff touches. No code fix applies — it's an account-level rate limit that self-resolves once the daily quota window rolls over, and the error message itself rules out a re-run helping before then. GitHub Actions' test/e2e/GitGuardian checks are the real CI here and are green or still running.

Generated by Claude Code

github-actions · 2026-09-07T11:40:39Z