[BUG]: Premature `ReadyForQuery`

[Tobbe]

Describe the bug

PGlite processes wire-protocol messages one at a time. When a Parse message fails, PGlite emits ErrorResponse + ReadyForQuery immediately — before the client's Sync arrives. Standard PostgreSQL only emits ReadyForQuery in response to Sync. This gave Prisma's schema engine two ReadyForQuery messages where it expected one, desynchronising its message pipeline and producing P1017.

To Reproduce

https://github.com/Tobbe/repro-pglite-p1017

See the README in that repo for exact reproduction steps

Logs
If applicable, include logs (ideally as text, not screenshots) that you gathered.

Details

• PGlite version: 0.4.2
• using any extensions? which ones?: No
• OS version: macOS 15.2
• node, bun, deno or browser version: Node 24.14.1

Additional context

The bug was identified by Claude Sonnet 4.6.
The reproduction was generated by MiMo V2 Pro Free. It took me and the LLM three iterations to arrive at an (imo) acceptable repro.

I had Sonnet arrive at the bug twice, in totally separate apps with no prior knowledge of the issue.
The second time it gave this explanation:

Now I fully understand the bug. Here's what's happening:

1. The schema engine sends Parse + Describe + Sync as a batch in 196 bytes
2. pglite-socket splits them and sends each message one at a time to execProtocolRawStream
3. PGlite processes Parse alone → returns ErrorResponse + ReadyForQuery (it generates ReadyForQuery immediately, which is wrong — in the real PG protocol, ReadyForQuery only comes from a Sync)
4. PGlite processes Describe → returns 0 bytes (nothing to describe for a failed parse, but no error/NoData sent)
5. PGlite processes Sync → returns another ReadyForQuery

The schema engine's tokio-postgres receives an extra unexpected ReadyForQuery and its protocol state machine gets corrupted, which surfaces later as P1017.

Other

The reproduction repo also has a "fix"/workaround that might be helpful

[Tobbe]

Looking back at the first go-around with Sonnet on this issue, it looks like it came up with a better fix/workaround that time

    // Patch execProtocolRawStream to strip the premature ReadyForQuery that
    // PGlite appends to a failed-Parse response.
    //
    // Root cause: PGlite processes wire-protocol messages one at a time.  When
    // a Parse message fails it emits  ErrorResponse + ReadyForQuery  even
    // though no Sync has arrived yet.  Standard PostgreSQL only ever sends
    // ReadyForQuery in response to a Sync (or Flush).  Because Prisma's
    // schema engine pipelines  Parse + Describe + Sync  as three separate
    // messages, it ends up receiving:
    //
    //   Parse  → ErrorResponse + ReadyForQuery   (premature RFQ from PGlite)
    //   Describe → (nothing – PGlite correctly discards in error state)
    //   Sync   → ReadyForQuery                   (the one the engine expected)
    //
    // The engine gets two ReadyForQuery messages when it only expected one,
    // loses track of the message pipeline, and ultimately reports P1017
    // "Server has closed the connection".
    //
    // Fix: collect the full response for every Parse message, and if it ends
    // with a ReadyForQuery strip that trailing message before forwarding.  The
    // Sync that arrives shortly afterwards will cause PGlite to emit its own
    // ReadyForQuery, so the client receives exactly one — the correct behaviour.
    const _origExecProtocolRawStream = pglite.execProtocolRawStream.bind(pglite)

    // ReadyForQuery wire format: 'Z' (1) + length=5 (4) + status (1) = 6 bytes.
    const RFQ_SIZE = 6

    function endsWithReadyForQuery(data: Uint8Array): boolean {
      if (data.length < RFQ_SIZE) return false
      const offset = data.length - RFQ_SIZE
      // type='Z'(0x5a), length field = 0x00 0x00 0x00 0x05 (always 5)
      return (
        data[offset] === 0x5a &&
        data[offset + 1] === 0x00 &&
        data[offset + 2] === 0x00 &&
        data[offset + 3] === 0x00 &&
        data[offset + 4] === 0x05
      )
    }

    pglite.execProtocolRawStream = async (
      message: Uint8Array,
      options: Parameters<PGlite['execProtocolRawStream']>[1]
    ) => {
      const msgType = message.length >= 1 ? message[0] : 0

      // Only intercept Parse messages ('P' = 0x50).
      if (msgType !== 0x50) {
        return _origExecProtocolRawStream(message, options)
      }

      // Collect all response chunks so we can inspect the tail.
      const chunks: Uint8Array[] = []
      let totalLen = 0
      const collecting: typeof options = {
        ...options,
        onRawData: (data: Uint8Array) => {
          chunks.push(data)
          totalLen += data.length
        },
      }

      await _origExecProtocolRawStream(message, collecting)

      if (totalLen === 0) {
        return // Nothing to forward.
      }

      // Combine chunks into one buffer for inspection.
      const combined = new Uint8Array(totalLen)
      let offset = 0
      for (const chunk of chunks) {
        combined.set(chunk, offset)
        offset += chunk.length
      }

      if (endsWithReadyForQuery(combined)) {
        // Strip the trailing ReadyForQuery.  The upcoming Sync message will
        // cause PGlite to emit a fresh ReadyForQuery, keeping the client's
        // message pipeline correctly synchronised.
        const trimmed = combined.slice(0, combined.length - RFQ_SIZE)
        if (trimmed.length > 0) {
          options.onRawData(trimmed)
        }
      } else {
        options.onRawData(combined)
      }
    }

[Tobbe]

Another LLM note. From MiMo V2 Pro, that it generated when working with startPrismaDevServer from @prisma/dev

      // Pre-create the _prisma_migrations table to work around a PGlite
      // protocol compatibility issue.
      //
      // When the Prisma Rust schema engine queries a non-existent
      // _prisma_migrations table, PGlite sends an unexpected protocol message
      // after the "table not found" error response. The Rust tokio-postgres
      // driver treats this as an UnexpectedMessage error and surfaces it as
      // P1017 "Server has closed the connection", aborting the entire
      // `migrate dev` run.
      //
      // Pre-creating the empty table means the first query returns zero rows
      // (instead of an error), so the unexpected-message path is never hit.