test: raw-query golden harness for @prisma/adapter-pg (TRI-13039 spike) - #4535
Conversation
Spike evidence only, not for merge. Adds a testcontainers harness that runs the same raw queries through the current Rust-engine Prisma client and an @prisma/adapter-pg client against the same Postgres, plus a tracing gate. - Deliverable A: engine spans (prisma:client:operation, prisma:engine:db_query, prisma:engine:connection) survive the adapter under driverAdapters-alone. - Deliverable B: 10/11 raw-result shapes byte-identical; only unqualified SQL on a non-public schema diverges (#28128), inert for the public-schema prod DBs. Enables the driverAdapters preview flag on both schemas (regen required, not committed).
|
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (6)
WalkthroughPrisma generators now enable the ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
What this is
Timeboxed spike for TRI-13039. Evidence, not a migration: a golden test harness that answers whether
@prisma/adapter-pgat Prisma 6.14 (a) preserves engine tracing and (b) returns byte-identical raw-query results vs the current Rust engine. Nothing here is meant to merge; it enables thedriverAdapterspreview flag on both schemas (regen required, not committed) and adds three test files underinternal-packages/testcontainers/src/.Run it:
Deliverable A — does tracing survive the adapter? PASS
In-memory OTel span exporter +
PrismaInstrumentation, sameSELECTthrough both clients.prisma:client:operationANDprisma:engine:db_queryboth present under the adapter.driverAdaptersalone keeps the Rust query engine, as predicted.prisma:engine:connectionSURVIVES: the pool-wait monitors keep reading a real span (it now measures node-postgres pool acquisition; same name/shape).prisma:engine:js:query:*spans (the node-postgres wire path), and DROPS two one-time Rust-binary bootstrap spans (detect_platform,load_engine) that no monitor reads.Deliverable B — raw-result equivalence matrix: 10/11 identical
= ANY($1::text[]))array_agg, text[] column)to_jsonb($1::text/::int)){schema}bigint stays bigint, NUMERIC stays
Prisma.Decimal, text[] stays a JS array, timestamptz stays aDate. The four feared upstream bugs (#24338, #27823, #23926, #28629) did NOT reproduce at 6.14: result deserialization is still done by the Rust engine, so the adapter changes the wire, not the JS types.Shape 10 (the one divergence, #28128)
The adapter's
{schema}option does not set a sessionsearch_pathfor raw SQL:{schema:"s1"}+ unqualifiedSELECT ... FROM t(non-public): FAILSP2010 / 42P01 relation "t" does not exist{schema:"public"}+ unqualified select: OKs1.tunder{schema:"s1"}: OKBoth prod connection strings use
?schema=public, andpublicis always on the default search_path, so the many unqualified raw queries resolve fine under the adapter. Real divergence, inert for current usage; would only bite a non-public schema, of which there are none.Revised effort estimate (replaces 4-6 weeks)
The 4-6 week estimate priced the 64 raw-SQL call sites as the risk. They are not: every wire type is unchanged and the feared bugs did not reproduce, so the raw-SQL surface is close to a no-op. The genuine work is adapter-inherent and non-query:
$metricsremoval (Prometheus route + 16db.pool.connections.*OTel instruments need a new source, the largest item), error-code remapping (P1001/P1017->ECONNREFUSED/ENOTFOUND;40P01no longer ->P2034, so deadlocks stop retrying, #29716;P2024gone; eager$connect()no-op, #28959), the load-bearingpgpin (<8.17, #29035), and RBAC/SSO plugin clients outside this repo.Grounded estimate: roughly 1.5-2.5 weeks, dominated by the pool-observability replacement, not query rewrites.
Go / no-go
GO. The mechanism holds under test: engine spans (incl.
engine:connection) survive, and raw results are byte-identical on 10/11 shapes with the one divergence provably inert for the public-schema DBs. The rejection was priced on a raw-SQL risk the evidence does not support; adoption is an observability + error-handling change, not a query-rewrite change.Not in scope
No adoption, no schema changes merged, no prod/staging config, no rollout. The regenerated Prisma clients are gitignored and not committed; adoption would enable
driverAdaptersand regenerate.refs TRI-13039