Better stack traces

[bdharrington7]

Hi Vitaly, I have been struggling for a while with how some of the stack traces in errors caught from calls to different pg-promise functions, and I've gone as far as wrapping each call to the main pgdb client in as small of a try-catch as possible, but that still only gives me an approximation of where an error occurs, especially if the try block has to encapsulate a couple calls (like in a transaction). I think I've come up with a pretty good solution now, using proxies:

https://codereview.stackexchange.com/questions/275071/proper-use-of-a-javascript-proxy-for-better-stack-traces-from-external-libraries

Because I'm using your library as an example, I thought maybe your eyes could see some better ways to approach this problem.

What do you think?

[tomskopek]

Also wondering what the current best practice is for this in 2022, with Node 16 as current stable version?

To be honest, if the error would include the full query it is trying to parse that would be very helpful in hunting down which query is failing. Do you think this is possible @vitaly-t? [1]

I went through the previous issues on the topic:
#342
#166
#496
https://stackoverflow.com/questions/63079026/friendly-stack-traces-with-pg-promise-for-query-errors

Seems like bluebird is always the recommended approach, but the github of bluebird states to use native promises if possible: https://github.com/petkaantonov/bluebird#%EF%B8%8Fnote%EF%B8%8F

Sorry @vitaly-t you are probably sick of answering this question 😛

[1] Eg: (copying an example from previous issue)

db.query('SELECT error').catch(err => console.error(err));

currently this would throw:

{ error: column "error" does not exist
    at Connection.parseE (.../node_modules/pg-promise/node_modules/pg/lib/connection.js:539:11)
    at Connection.parseMessage (.../node_modules/pg-promise/node_modules/pg/lib/connection.js:366:17)
    at Socket.<anonymous> (.../node_modules/pg-promise/node_modules/pg/lib/connection.js:105:22)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:191:7)
    at readableAddChunk (_stream_readable.js:178:18)
    at Socket.Readable.push (_stream_readable.js:136:10)
    at TCP.onread (net.js:561:20)
  name: 'error',
  length: 97,
  severity: 'ERROR',
  code: '42703',
  detail: undefined,
  hint: undefined,
  position: '8',
  internalPosition: undefined,
  internalQuery: undefined,
  where: undefined,
  schema: undefined,
  table: undefined,
  column: undefined,
  dataType: undefined,
  constraint: undefined,
  file: 'parse_relation.c',
  line: '2892',
  routine: 'errorMissingColumn' }

Would be cool if the error would include the query SELECT error text somewhere

[vitaly-t]

Seems like bluebird is always the recommended approach, but the github of bluebird states to use native promises if possible: https://github.com/petkaantonov/bluebird#%EF%B8%8Fnote%EF%B8%8F

Ignore what they say there, and continue to use Bluebird, their stack tracing is far superior than the native Promise:

const Promise = require('bluebird');
const initOptions = {
    promiseLib: Promise
};
const pgp = require('pg-promise')(initOptions);

And then activate longStackTraces as documented here.

[tomskopek]

Thanks @vitaly-t

I'm always impressed by your quick replies 🏆

By the way - Any comment on my question about including the failing query in the error message?

[vitaly-t]

@tomskopek The library provides custom errors only for specific situations. It does not handle server-side generic errors.

But you have event error that reports query details:

const initOptions = {
    error(err, e) {
       // here, you have r.query + e.params
    }
};

[tomskopek]

Sorry for the delay responding. I'm not sure I understand how to use this properly.

I added error like so:

const initOptions:  IInitOptions<IExtensions> = {
  extend(obj: ExtendedProtocol, dc: any) {
    obj.users = new UsersRepository(obj, pgp)
    ...
  },
  error(err, e) {
    console.log('err | initOptions');
    console.log(err);
    console.log('e.query | initOptions');
    console.log(e.query);
  },
  capSQL: true,
}

These logs do not show up when something like this throws an error (simple example):

const columnSet = new this.pgp.helpers.ColumnSet(['name'], { table: 'users' })
const sql = this.pgp.helpers.insert({ foo: 'bar' }, columnSet) + ' RETURNING id' // this will throw an error: Error: Property 'name' doesn't exist. But the error callback in initOptions does not get called

Is that expected? In what scenario would that error callback get called?

Thanks!

[vitaly-t]

Is that expected? In what scenario would that error callback get called?

Yes. The error handler inside init options is for query executions only. Formatting issues that you show do not execute any query. If you want those included into generic error report, then you need to wrap them into a function:

db.none(() = {
    // ....
    return this.pgp.helpers.insert({ foo: 'bar' }, columnSet) + ' RETURNING id';
});

i.e. all query functions support a function as parameter, to return the query, and that will join the general error handling.

[tomskopek]

Ok, I understand.

The e.query log in my example now looks like this, which is not super helpful 🙃:

const columnSet = new this.pgp.helpers.ColumnSet(['name'], { table: 'users' })
const sql = await this.db.none(() => this.pgp.helpers.insert({ foo: 'bar' }, columnSet) + ' RETURNING id');

  console.log
    e.query | initOptions

      at Object.error (src/index.ts:44:13)

  console.log
    [Function (anonymous)]

      at Object.error (src/index.ts:45:13)

Anyways, thanks all the same 😃

[GabenGar]

Since errors now include the query, it got me thinking if pg-promise can infer the exact line of pre-formatted errored query from the line/column info of the error? Technically it knows the full pre- and post-formatted queries, and it knows at which indexes interpolations took place, so it should be able to map the offending line/column from the formatted query to the pre-formatted one.

[vitaly-t]

Since errors now include the query, it got me thinking if pg-promise can infer the exact line of pre-formatted errored query from the line/column info of the error? Technically it knows the full pre- and post-formatted queries, and it knows at which indexes interpolations took place, so it should be able to map the offending line/column from the formatted query to the pre-formatted one.

pg-promise does not parse queries, and it doesn't track any line numbers either. It utilizes pg-minify though for shallow-parsing query files, but those are only reported when such queries are invalid.