Bun/Drizzle dashboard hits extended protocol decode/result-format errors in transaction mode

[joelzanden]

Summary

Using PgDog in front of PostgreSQL for a Bun/Drizzle dashboard app in transaction mode appears to corrupt extended-protocol result handling intermittently and sometimes on very simple SELECT queries.

We are seeing repeated client-side decode failures plus a server-side protocol mismatch symptom:

• ERR_POSTGRES_UNSUPPORTED_INTEGER_SIZE
• Failed to read data
• TypeError: undefined is not an object (evaluating 'a.toISOString')
• bind message has 2 result formats but query has 17 columns

This is happening in staging while routing reads through PgDog to replicas and writes to primary.

Environment

• PgDog image: ghcr.io/pgdogdev/pgdog:0.1.30
• Helm chart revision: v0.46
• Kubernetes deployment, 2 PgDog replicas
• Pooler mode: transaction
• Prepared statements: extended_anonymous
• Auth: passthrough_auth = "enabled_plain"
• TLS verify upstream: prefer
• Client: Bun 1.3.11
• ORM: Drizzle bun-sql
• App: Next.js dashboard server components / server actions

Relevant PgDog config:

[general]
pooler_mode = "transaction"
read_write_strategy = "conservative"
read_write_split = "exclude_primary"
prepared_statements = "extended_anonymous"
passthrough_auth = "enabled_plain"
tls_verify = "prefer"

[[databases]]
name = "ndr"
host = "ha-postgres-primary"
port = 5432
role = "primary"

[[databases]]
name = "ndr"
host = "ha-postgres-replicas"
port = 5432
role = "replica"

Symptoms

The failure shows up when listing datasets and then clicking a dataset row to navigate into the dataset page.

The affected queries can be extremely simple, for example:

select "id", "name"
from "ndr"."datasets"
where "ndr"."datasets"."slug" = $1

and also:

select "id", "slug", "name", "owner", "description", "retention_days", "pii_classification", "default_storage_area", "created_at", "updated_at"
from "ndr"."datasets"
where "ndr"."datasets"."slug" = $1

and:

select "ndr"."pipelines"."id", "ndr"."pipelines"."name", "ndr"."pipelines"."dataset_id", "ndr"."datasets"."slug", "ndr"."pipelines"."description", "ndr"."pipelines"."owner", "ndr"."pipelines"."created_at", "ndr"."pipelines"."updated_at", "ndr"."pipelines"."config", "ndr"."pipelines"."current_revision_id", "ndr"."pipelines"."allow_duplicates", "ndr"."pipelines"."active", "ndr"."pipelines"."concurrency_limit", "ndr"."pipelines"."default_job_options", "ndr"."pipelines"."last_run_at", "ndr"."pipelines"."last_status", "ndr"."pipelines"."deleted_at"
from "ndr"."pipelines"
inner join "ndr"."datasets" on "ndr"."pipelines"."dataset_id" = "ndr"."datasets"."id"
where ("ndr"."datasets"."slug" = $1 and "ndr"."pipelines"."deleted_at" is null)
order by "ndr"."pipelines"."created_at" desc

We also saw this logged from the app side:

Failed query: select "id", "dataset_id" from "ndr"."pipelines" where "ndr"."pipelines"."deleted_at" is null
params:
: bind message has 2 result formats but query has 17 columns

And many repeated errors like:

PostgresError: Failed to read data
code: 'ERR_POSTGRES_UNSUPPORTED_INTEGER_SIZE'

Notes

• This does not look like a SQL parser / read-write routing issue. The same failures happen on very simple SELECTs.
• PgDog logs do not show parser failures; mostly normal connect/disconnect with occasional Connection reset by peer.
• We previously saw intermittent TypeError: undefined is not an object (evaluating 'a.toISOString'), which may be a downstream effect of corrupted / mismatched result decoding.
• The client uses Bun's built-in Postgres driver through Drizzle. We are not using node-postgres.

Question

Does this look like another extended protocol / prepared statement / result format bug in PgDog transaction mode?

In particular, does extended_anonymous have known incompatibilities with Bun's driver when result format metadata changes across binds or pooled backend connections?

[levkk]

Hi!

Thanks for reporting this. I think we may have fixed this in v0.1.31, but I'm not certain since I've gotten conflicting reports on this one. Would you be able to reproduce this locally, and if so, would you be able to provide us with trace logs?

export RUST_LOG=trace

I believe this to be a race condition: we were processing a client's request even if they abruptly disconnected before receiving the response. We didn't detect this situation and gave the response from the previous client to the next one which re-used the same server connection. This was fixed in 0.1.31 and only affected clients that used pipelining (multiple queries sent asynchronously), which I know Drizzle does. So, on the surface, it feels like we may have addressed it, but I would certainly like to be sure.

So, ideally, if you can repro with 0.1.30, save the logs, and retry with 0.1.31 and confirm it doesn't happen anymore, that would be amazing.

Thanks!

[joelzanden]

Thank you!
I dug further and it looks like we probably mixed up two separate problems.

One part was likely on me: I found a dashboard query bug that could blow up in Bun/Drizzle with:
TypeError: undefined is not an object (evaluating 'a.toISOString')

That said, we were also definitely running PgDog 0.1.30 in staging, and the original errors in this issue still feel different from that app bug, especially things like:

• bind message has 2 result formats but query has 17 columns
• ERR_POSTGRES_UNSUPPORTED_INTEGER_SIZE
• Failed to read data

So my current guess is:

• the toISOString crash was our bug
• the earlier protocol/decode errors may still have been the PgDog 0.1.30 issue you mentioned

I’ll retry with RUST_LOG=trace, and after that with a newer PgDog version and separate app-side bugs from PgDog-specific failures.