[pyramation]

Summary

routing_planes().resolver_schema_name now comes from each route_module's private_schema_id, not its schema_id. The test fixture gives each plane a separate private schema.

Link to Devin session: https://app.devin.ai/sessions/ea7371d8dbc441c49cb46e16d1d97517
Open in Devin Desktop: https://app.devin.ai/desktop/session/ea7371d8dbc441c49cb46e16d1d97517?variant=devin
Requested by: @pyramation

[devin-ai-integration]

I'll fix CI failures and address comments from users with write access. I'll skip comments containing "(aside)".

• Disable automatic comment, CI, and merge conflict monitoring

[tenki-reviewer]

Review complete. 🟡 2 medium

💬 Inline comments (2)

• 🟡 resolver_schema_name now returns private schema prematurely — routing_planes.sql:29
• 🟡 Regenerate the stale bundle artifact via pgpm package — pgpm-function-resolution--0.47.7.sql:2414

---

This PR switches function_resolution.routing_planes() to return the route module's private schema name as resolver_schema_name via a LEFT JOIN on route_module.private_schema_id, updates the test fixtures to expect ${name}_routing_private values, and mirrors the change into the generated sql/ artifact. However, nothing in this change generates a resolver into the private schema — the removed comment says readers are still generated publicly "for now" — and private_schema_id defaults to uuid_nil(), so legacy rows yield a NULL resolver_schema_name for the platform router. The bundled artifact was also hand-edited without regenerating the .bundle.tar.gz.

Files	Change
packages/function-resolution/deploy/schemas/function_resolution/procedures/routing_planes.sql	resolver_schema_name now comes from the private schema via LEFT JOIN on private_schema_id
packages/function-resolution/sql/pgpm-function-resolution--0.47.7.sql	Mirrors the new function definition, but the committed bundle artifact is stale
packages/function-resolution/tests/request-lane-reads.test.ts	Fixtures insert private-schema rows and assert resolver_schema_name from the private schema

_{Reviewed commit: f6cafd1}

[tenki-reviewer]

Repoints resolver_schema_name in routing_planes() at the route module's private schema, with matching test fixtures and regenerated sql artifact, but the resolver is still generated into the public schema so premature.

Key findings

• 🟡 resolver_schema_name now returns private schema prematurely — routing_planes.sql:29
• 🟡 Regenerate the stale bundle artifact via pgpm package — pgpm-function-resolution--0.47.7.sql:2414

[tenki-reviewer]

🟡 bug · medium

resolver_schema_name now returns private schema prematurely

function_resolution.routing_planes() now returns ps.schema_name as resolver_schema_name, joined via route_module.private_schema_id (packages/function-resolution/deploy/schemas/function_resolution/procedures/routing_planes.sql:29). The removed comment stated the readers are still generated into the public schema and that this column should only switch when they move, and nothing in this change or the repository generates a resolver into the private schema. Because private_schema_id is NOT NULL DEFAULT uuid_nil() (packages/metaschema-modules/deploy/schemas/metaschema_modules_public/tables/route_module/table.sql:27), rows without an explicit private schema now yield a NULL resolver_schema_name instead of the public schema name, so the platform router qualifying the resolver from this column points at the wrong schema or a non-schema on upgraded or provisioned databases.

📋 Prompt for AI Agents

In packages/function-resolution/deploy/schemas/function_resolution/procedures/routing_planes.sql line 29, change ps.schema_name::text to COALESCE(ps.schema_name, s.schema_name)::text so rows whose private_schema_id is still the uuid_nil() default (or whose readers are not yet generated into the private schema) keep returning the public schema name as resolver_schema_name. Mirror the change in packages/function-resolution/sql/pgpm-function-resolution--0.47.7.sql and the test expectations in packages/function-resolution/tests/request-lane-reads.test.ts, and regenerate the sql artifacts with pgpm package in the same commit.

[tenki-reviewer]

🟡 bug · medium

Regenerate the stale bundle artifact via pgpm package

The change to routing_planes.sql was mirrored by a hand edit in packages/function-resolution/sql/pgpm-function-resolution--0.47.7.sql:2414, but sql/pgpm-function-resolution--0.47.7.bundle.tar.gz was not regenerated in this commit. pgpm deploy --fast verifies the bundle's sha256 and executes it one-shot, so it would deploy the stale routing_planes() that still returns the public schema name. AGENTS.md requires both generated artifacts to be regenerated in the same commit as any deploy/ change and forbids hand-editing them.

📋 Prompt for AI Agents

In packages/function-resolution, run pgpm package so sql/pgpm-function-resolution--0.47.7.sql and sql/pgpm-function-resolution--0.47.7.bundle.tar.gz are both regenerated from deploy/ in the same commit as the routing_planes.sql change, instead of hand-editing the sql artifact and leaving the bundle stale.