The 50-row cross-schema page has no runtime caller — so the #1216/#1326/#1960 family's behavioural tests no longer demonstrate their claim #2048

Activity

1. rbuergi commented on Aug 25, 2026

   

   rbuergi

   on Aug 25, 2026

   ContributorAuthor

   More actions

   Confirmed on origin/main @ 201a16aa7 — the claim holds precisely as written.

   • The 50-row paging form is PostgreSqlCrossSchemaQueryProvider.cs:289.
   • DefaultFanOutLimit is referenced only at :373 and :467 — i.e. inside that method only.
   • The runtime path takes the table form instead: PostgreSqlPartitionedMeshQuery.cs:908 → :632 → GenerateCrossSchemaSelectQuery at :678, which applies no default limit.
   • The only src/ callers of any overload are the two table-form ones (PG :908, Snowflake :436).

   So the behavioural tests in the #1216/#1326/#1960 family do still exercise the paging code, but nothing in the running system reaches it — which is exactly this issue's point: the tests no longer demonstrate the claim they were written to defend.

   Worth adding, since it bears on the family: the same fan-out limit was a leading hypothesis for the #2031/#2185 flake family, and that hypothesis was weakened tonight — the identical UserIdentityCache.WhenDetermined timeout signature reproduces in MeshWeaver.Hosting.Monolith.Test, whose base uses AddInMemoryPersistence() and therefore has no PostgreSQL cross-schema path at all. (That reproduction was taken on a loaded machine, so treat it as suggestive rather than settled — see my note on #2185.)
2. rbuergi commented on Aug 25, 2026

   

   rbuergi

   on Aug 25, 2026

   ContributorAuthor

   More actions

   Decision: retire the paging form. #2282 does it.

   Re-measured first, and the premise holds on ed4588222: the paging shape is PostgreSqlCrossSchemaQueryProvider.cs:289; DefaultFanOutLimit is referenced only at :373/:467, both inside it; the runtime path takes the table form (PostgreSqlPartitionedMeshQuery.cs:908 → the 6-arg overload → GenerateCrossSchemaSelectQuery, which emits LIMIT only for Limit is > 0). Same split on Snowflake. Grepping src, test, memex, samples, content and samples/*/Data: the paging form's only callers are tests.

   Why retire rather than wire

   1. The 50-row default is the defect, not a feature to restore. Batch bake's source discovery is truncated by the default query limit (50) — 169/237 types got zero sources in production #1216, GitSync reports "Skipped (0 nodes)" while a space is behind (_Activity/import-{hash} fingerprint), and force-prune eats Release records (AddIfUnderPrefix case-sensitivity) #1326 and fix: the portal read its user directory as a search page, so most viewers lost their time zone (#1936) #1960 are three filings of the same silent truncation. The runtime's actual behaviour — an unpinned query returns everything — is the one those issues' remedy argued for. Wiring the paging form would reintroduce, deliberately, the thing three issues were opened to remove.
   2. It was a second access-control implementation. The search_across_schemas stored function gates access in plpgsql; the table form gates it in the generated per-schema user_effective_permissions clause. Two implementations of one logical query, one of them unexercised, is where a security fix lands on the wrong copy — and the security-fold tests were already split across the two, so half of them exercised code no request could reach.
   3. If a bound is ever wanted, it belongs on the ONE shape the runtime executes and it has to be loud. That is a separate decision with Batch bake's source discovery is truncated by the default query limit (50) — 169/237 types got zero sources in production #1216/GitSync reports "Skipped (0 nodes)" while a space is behind (_Activity/import-{hash} fingerprint), and force-prune eats Release records (AddIfUnderPrefix case-sensitivity) #1326's evidence against it, not a reason to keep a dead second path warm.

   Deleting it surfaced three live problems — which is the argument in miniature

   • 🚨 Mesh-wide keyset paging had never worked in production. Mesh-wide (cross-partition) queries: sort:path errors 42703 and path:> keyset filter silently matches nothing #2186 fixed sort:path erroring 42703 column "path" does not exist — on the stored function. The runtime shape still 42703'd. CrossPartitionKeysetPagingTests went red the instant it was pointed at the overload the runtime takes. Both SQL generators now project path on every union branch.
   • The fan-out timing instrumentation had produced not one line in production — LogFanOutTiming's only production caller was the paging form. Moved onto the table form, in a finally so an abandoned enumeration still reports.
   • Complete() meant different things on the two backends — Snowflake dropped NoLimit (is > 0) where PG propagates it. Aligned.

   On Complete() and the family's tests

   Complete() stays, with its contract restated exactly rather than quietly overclaimed: it is the declaration that a read is an enumeration, and it overrides a limit that reaches the request (notably a limit:N carried in a query STRING, which is how a permission read actually gets truncated — SecurityQueries.Enumeration replaces such a token). It is no longer credited with defeating a truncation the runtime does not perform. UserDirectoryCompletenessTests now says outright that removing .Complete() leaves its behavioural test passing and only its property test failing, and why that is the correct division of labour.

   public.search_across_schemas stays in the schema — an older replica mid-rollout still calls it.
3. rbuergi

   added a commit that references this issue on Aug 25, 2026

   Merge pull request #2282 from Systemorph/worktree-agent-a99f3fe375036…

   ...

   e3a7420
4. rbuergi

   closed this as completedin #2282on Aug 25, 2026