The recursive relationship call sites in resources/search.ts (the relationship.to / relationship.from join paths inside searchByIndex) and the relationship resolver call in resources/Table.ts (returnEntry path, ~line 4960) do not pass context through to the inner searchByIndex call. The inner search therefore reads the related table without the request's transaction/context, while the outer search uses it.
This is pre-existing behavior — on the pre-#2165 positional signature those call sites already stopped short of the context parameter (5 and 6 positional arguments respectively), so context was undefined there long before the refactor. It was surfaced by Gemini Code Assist review on #2187, which deliberately did not change it: that PR is scoped as a mechanical, no-behavior-change reshape (#2165), and threading context is a behavior change that deserves its own review — the join paths would start reading the related table under the request's read snapshot instead of the default read transaction.
Worth deciding as part of this: whether the inner joins should see the request transaction (consistency argument) and whether any caller depends on the current unsnapshotted reads. The declined review threads on #2187 carry the call-site-by-call-site analysis.
Raised out of #2187 / #2165. Now that the optional tail is an options object, the fix itself is small: add context (and likely the transaction) to the inner calls' options at the three sites, plus tests pinning snapshot semantics across a join.
The recursive relationship call sites in
resources/search.ts(therelationship.to/relationship.fromjoin paths insidesearchByIndex) and the relationship resolver call inresources/Table.ts(returnEntrypath, ~line 4960) do not passcontextthrough to the innersearchByIndexcall. The inner search therefore reads the related table without the request's transaction/context, while the outer search uses it.This is pre-existing behavior — on the pre-#2165 positional signature those call sites already stopped short of the
contextparameter (5 and 6 positional arguments respectively), socontextwasundefinedthere long before the refactor. It was surfaced by Gemini Code Assist review on #2187, which deliberately did not change it: that PR is scoped as a mechanical, no-behavior-change reshape (#2165), and threadingcontextis a behavior change that deserves its own review — the join paths would start reading the related table under the request's read snapshot instead of the default read transaction.Worth deciding as part of this: whether the inner joins should see the request transaction (consistency argument) and whether any caller depends on the current unsnapshotted reads. The declined review threads on #2187 carry the call-site-by-call-site analysis.
Raised out of #2187 / #2165. Now that the optional tail is an options object, the fix itself is small: add
context(and likely the transaction) to the inner calls' options at the three sites, plus tests pinning snapshot semantics across a join.