Bigint precision loss in SQL queries with relations

[gskril]

Version

0.15.13

Current behavior

The relational parts of SQL queries in API endpoints return bad data (first ~16 chars are the same, then the rest is different).

For example I had an API endpoint with this logic:

const accountWithVotes = db.query.account.findFirst({
  where: (cols, { eq }) => eq(cols.address, address),
  with: {
    voteCasts: true
  }
})

return accountWithVotes

Where this is the schema:

export const account = onchainTable('account', (t) => ({
  address: t.hex().primaryKey(),
  delegate: t.hex(),
  votes: t.bigint(),
}))

export const voteCastEvent = onchainTable('voteCastEvent', (t) => ({
  id: t.text().primaryKey(),
  timestamp: t.bigint().notNull(),
  transaction: t.hex().notNull(),
  voter: t.hex().notNull(),
  proposalId: t.bigint().notNull(),
  proposalStartTimestamp: t.bigint().notNull(),
  support: t.integer().notNull(),
  weight: t.bigint().notNull(),
  reason: t.text().notNull(),
}))

export const accountRelations = relations(account, ({ many }) => ({
  voteCasts: many(voteCastEvent),
}))

The resulting accountWithVotes.voteCasts.proposalId is wrong (see expected behavior)

Expected behavior

I changed the API code to be this, which works as intended. I would expect it to return the same data as earlier, but voteCasts.proposalId is a different value.

const account = await db.query.account.findFirst({
  where: (cols, { eq }) => eq(cols.address, address)
})

const voteCasts = await db.query.voteCastEvent.findMany({
  where: (cols, { eq }) => eq(cols.voter, address)
})

return {
  ...account,
  voteCasts,
}

Steps to reproduce

No response

Link to repository

No response

Anything else?

No response

[typedarray]

Thanks for opening. Are you able to reproduce this using both Postgres and PGlite?

EDIT: We've had very similar issues in the past that resemble this issue in Drizzle. It's kind of inherent to how Drizzle Relations work.

[gskril]

Ah that's unfortunate given bigints are so common in the EVM, but thanks for the reference. Probably worth calling out in the docs!

I noticed the issue on a project running on Marble via Neon, which I believe is Postgres.

[iherger]

We are also seeing this using Postgres.