neondatabase / serverless

Connect to Neon PostgreSQL from serverless/worker/edge functions
https://www.npmjs.com/package/@neondatabase/serverless
MIT License
344 stars 13 forks source link

The "neon" and "Pool" methods of querying do not return the same error information #51

Closed sabercoy closed 4 months ago

sabercoy commented 11 months ago

Currently, on database error, using the neon "one-shot" method will throw a NeonDbError which contains three keys: name, code, and sourceError. I am finding that querying with a Pool allows me to view all error information, namely "contraint." I am wondering if it is possible for them to return the same things so that I can use the neon method for lower latency.

Thanks and I love the package!

jawj commented 11 months ago

Thanks for raising this.

@conradludgate Can we see if it's possible to expose more error details for HTTP/JSON queries?

We try to mirror node-postgres/pg, whose error objects seem to be typed as follows (pg-protocol package, /src/messages.ts):

interface NoticeOrError {
  message: string | undefined
  severity: string | undefined
  code: string | undefined
  detail: string | undefined
  hint: string | undefined
  position: string | undefined
  internalPosition: string | undefined
  internalQuery: string | undefined
  where: string | undefined
  schema: string | undefined
  table: string | undefined
  column: string | undefined
  dataType: string | undefined
  constraint: string | undefined
  file: string | undefined
  line: string | undefined
  routine: string | undefined
}

And I guess this simply reflects what Postgres provides, since the tokio-postgres DbError struct looks pretty similar.

jawj commented 9 months ago

@conradludgate I was just setting out to copy these fields across to the NeonDbError that's thrown by the driver. But a few observations:

Thanks!

conradludgate commented 9 months ago
  • In the node-postgres version, all the fields are strings. But line seems to come back from the API as a number.
  • I think it should be dataType rather than datatype.

Ah, interesting. I can sort that.

  • I see // TODO(conrad): db_error.position() in the code. Is this a near-term thing I could wait for, or something tricky and low-priority?
  • We also don't replicate internalPosition or internalQuery. I'm not honestly sure what those are, but node-postgres seems to copy them over from the psql message too.

Hmm, I don't quite recall why I didn't include those. https://docs.rs/tokio-postgres/latest/tokio_postgres/error/enum.ErrorPosition.html. Maybe I just got a bit confused. Should be easy to add

  • Maybe we could trim down the message? Where node-postgres gives error: column "oog" does not exist, the API rather goes to town with db error: ERROR: column "oog" does not exist\n\nCaused by:\n ERROR: column "oog" does not exist.

Yeah, good point