pg-promise: Stack trace unhelpful for invalid queries that end in error
This was brought up to a degree in #166, but I don’t think was followed on because the original reporter solved his specific problem, but the core problem with the stack traces remains. Here’s a really simple test case:
let db = require('pg-promise')()(require('config').rds);
db.query('select error').catch(err => console.error(err));
I would expect that the stack trace would tell me what part of the query fails (it does), as well as from where the query was invoked (it doesn’t). Not having the latter makes it REALLY hard to troubleshoot in anything but a simple app or test case. Here’s the output of the above test case (directories sanitized):
❯ node ./pg-promise-test.js
{ 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' }
You’ll notice that nowhere in the stack trace does it actually reference the line in the test case that actually caused the error, making the source of the problem damn near impossible to find in non-trivial cases. This is not an issue when using the callback-based approach in node-postgres.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 6
- Comments: 21 (10 by maintainers)
Dude, relax, you seem to be just oozing with condescension, insinuating that I have no idea how Promises work. I’m just trying to highlight a pain point that you yourself are aware. I’m suggesting that if you KNOW bluebird with long stack traces is the only way to get useful stack traces out of pg-promise, it MIGHT be worth noting in your section of documentation dedicated to Promise lib support. You don’t have to take this suggestion as a persona affront, it’s just feedback from a user, not an attack on your project or prowess as a developer. Do with my suggestion what you will.
@vitaly-t Thanks, I get it, that’s always a possibility, it’s just node’s async stack traces have 0
performance impact and are enabled by default. So it’s much more accessible for regular users.
Not so much noting that bluebird supports long stack traces, but that ES6 stack traces (default) WON’T be helpful and that you should use an alternative lib to get them. You’re right, stack traces are the realm of the Promise implementation, but not all libs are affected as negatively as pg-promise appears to be WRT stack traces, hence my initial concern.
Happy to PR, so long as you can drop the condescending comments. I’d much rather be a contributor than some unfairly perceived insurgent on your repo.
Native promises, aka ES6 Promises are part of Node.js since v0.11, not this library.
Bluebird isn’t just another promise library. It is The promise library that should be used today, also the only one that does stack tracing so well.
The standard ES6 Promise is too basic anyway, don’t expect much from it.