bindContextToTransaction lists members by hand and nothing tests that it carries them

[borisno2]

Found while verifying a base merge on PR #1338, 2026-09-08. Targets prisma-8, not main.

Problem

#1332 added _config to AccessContext, carried in both literal rebuilds — getContext and bindContextToTransaction. The carry in bindContextToTransaction is untested.

Deleting that line leaves the entire workspace green: packages/core 1695 tests and packages/rag 470 tests all still pass.

Why it is invisible today, and when it stops being

The shipped RAG plugin reads the context its runtime factory closed over, so it never observes the rebuilt one. A plugin that instead uses a hook's own context — the indirection docs/content/how-to/rag-advanced.md documents — would get a context with no _config as soon as its write ran inside a transaction, and break.

So the gap is real, it is reachable by a documented pattern, and nothing in the suite would report it.

bindContextToTransaction is a member-listing rebuild rather than a spread, which is the shape that silently drops a member whenever someone adds one. That is not hypothetical: two changes appended optional members to this same type on the same day, and a sibling pull request hit three merge conflicts across exactly these literals.

What to build

• A test asserts the rebuilt context inside a transaction carries _config, and fails when the carry is removed
• The same for every other member bindContextToTransaction is responsible for — the risk is the rebuild shape, not this one member
• Consider whether that rebuild should spread the source context and override deliberately, rather than list members, so a newly added member is carried by default instead of by remembering

Evidence

A throwaway probe asserting _config === config by identity across five context-building paths — plugin runtime, hook context on a plain write, hook context inside a transaction, the sudo and session derivations, and a junction create — passed 5/5 on the merged tree. Deleting the carry from bindContextToTransaction failed 3 of the 5. The probe was not committed, so that evidence does not currently exist in the repository.

Notes

Not introduced by #1338 — surfaced by verifying its merge with #1332. Related: #1334, which records the same shape of gap on the error-to-form chain, and #1340, which records that test files are not type-checked.

[borisno2]

A concrete trap for whoever picks this up, found while writing a seam test for #1155 (PR #1335). 2026-09-08.

The obvious way to test that the transaction rebind carries a member is to exercise the feature that member powers. That does not work for the row-lock lane, and the resulting test passes while proving nothing.

An agent writing exactly that test found its first version passed with the lane dropped from the rebind. The reason:

• forUpdate() reaches its lane through the db delegate, which is built from the child getContext's own seat.
• The lane the rebind hands to transactionFace feeds only advisoryLock().

So a test driving forUpdate() never touches the hand-listed carry at all. The committed test asserts advisoryLock() on each derived context for that reason.

Why this sharpens the issue

It is a second instance of the same shape: a member is carried by hand, and the natural test for it reaches the capability by a different route, so the carry looks covered when it is not. First _config, now the lock lane — and in both cases deleting the line leaves a green suite.

That strengthens the last checkbox above. Testing each member individually is not just laborious, it is error-prone in a way that produces false confidence: the test author has to know which of several routes to a capability actually passes through the rebuild. Making the rebuild spread and override deliberately removes the question rather than answering it repeatedly.

• When adding coverage here, verify each new test by deleting the carry it names and confirming that specific test fails — not merely that some test does