Query errors with riverdatabasesql and Bun leadership.Elector: Error attempting to elect... ERROR: there is no parameter $2 (SQLSTATE=42P02)

[jhekasoft]

I have an error that keeps recurring when I use riverdatabasesql driver with sql.DB and Bun's driver pgdriver:

msg="leadership.Elector: Error attempting to elect" attempt=60 client_id=ff0776778fd5_2026_03_08T17_11_23_841380 err="ERROR: there is no parameter $2 (SQLSTATE=42P02)"

After researching, I realized that the cause was the apostrophe in the word doesn't in the comment in the generated file riverdriver/riverdatabasesql/internal/dbsqlc/river_leader.sql.go:

const leaderAttemptElect = `-- name: LeaderAttemptElect :execrows
INSERT INTO /* TEMPLATE: schema */river_leader (
    leader_id,
    elected_at,
    expires_at
) VALUES (
    $1,
    coalesce($2::timestamptz, now()),
    -- @ttl is inserted as as seconds rather than a duration because ` + "`" + `lib/pq` + "`" + ` doesn't support the latter
    coalesce($2::timestamptz, now()) + make_interval(secs => $3)
)
ON CONFLICT (name)
    DO NOTHING
`

The apostrophe in doesn't inside the -- comment triggers the QuotedString parser (format.go:189-207), which then greedily consumes the rest of the query template looking for a closing '. Since there's no matching ' after it, the entire remainder of the SQL — including the second $2 and $3 — is swallowed as if it were a string literal.

Libs versions:

github.com/riverqueue/river v0.31.0
github.com/riverqueue/river/riverdriver/riverdatabasesql v0.31.0

github.com/uptrace/bun v1.2.17
github.com/uptrace/bun/dialect/pgdialect v1.2.17
github.com/uptrace/bun/driver/pgdriver v1.2.17

Proposal

Remove the apostrophe from the SQL comment. Change doesn't to does not here:

river/riverdriver/riverpgxv5/internal/dbsqlc/river_leader.sql

Line 18 in 9352dc8

-- @ttl is inserted as as seconds rather than a duration because `lib/pq` doesn't support the latter

?

[brandur]

@jhekasoft Wow, thanks for tracking that down!

Did you open an issue on the Bun repository? If Bun can't handle single quotes in SQL comments, it's fairly clearly a Bun bug we're seeing here.

I'm not totally against the proposed fix, but I'd be afraid we'd have a regression again as soon as a new quote in a SQL comment was added. The safer approach would be to fix Bun.

[bgentry]

Agreed this should be reported as an issue to Bun—they should not be trying to quote parse within a comment. We could potentially merge the quick fix but it'll almost certainly appear again.