Improve error logging by logging full error object

[Nitin-Mohapatra]

This PR updates the logerror function in application.js to use console.error(err) instead of err.stack || err.toString().

This change improves error visibility, especially for complex or nested errors (like those thrown by Sequelize), and supports modern features like Error.cause.

Fixes: #6462

[jonchurch]

This is sane, but I do want a second set of eyes on this. One of those "after thinking about it I dont see any issues, someone plz find me some issues". We are often guarded about changing error contracts and logging structures (cc @wesleytodd @ctcpip), and this is stderr output on the server, it is never sent to the client. Conceivable that someone is parsing the strings... but idk? For clarity, this codepath only ever runs when the default error handler is invoked.

I left context for the original code in the issue here (old node console.error did not log stack)

What this change will do is log all enumerable properties of the error to stderr. It will nicely walk the cause chain for us, logging the enumerable properties it finds.

const inner = new Error('connection refused');
inner.code = 'ECONNREFUSED';
inner.host = '127.0.0.1';
inner.port = 5432;

const outer = new Error('query failed', { cause: inner });
outer.query = 'SELECT * FROM users';

Before (w/ err.stack):

Error: query failed
    at [eval]:7:13
    at runScriptInThisContext (node:internal/vm:143:10)
    at node:internal/process/execution:100:14
    at [eval]-wrapper:6:24
    at runScript (node:internal/process/execution:83:62)
    at evalScript (node:internal/process/execution:114:10)
    at node:internal/main/eval_string:30:3

After (w/ console.error(err)):

Error: query failed
    at [eval]:7:13
    at runScriptInThisContext (node:internal/vm:143:10)
    ... 4 lines matching cause stack trace ...
    at node:internal/main/eval_string:30:3 {
  query: 'SELECT * FROM users',
  [cause]: Error: connection refused
      at [eval]:2:13
      at runScriptInThisContext (node:internal/vm:143:10)
      at node:internal/process/execution:100:14
      at [eval]-wrapper:6:24
      at runScript (node:internal/process/execution:83:62)
      at evalScript (node:internal/process/execution:114:10)
      at node:internal/main/eval_string:30:3 {
    code: 'ECONNREFUSED',
    host: '127.0.0.1',
    port: 5432
  }
}

[IamLizu]

If anyone was parsing stderr, they'd likely want the extra information.
LGTM 👍

[bjohansebas]

@Nitin-Mohapatra, could you please do a rebase? The branch is very out of date, and I can’t merge it, nor can I edit the PR.

[myselfsiddharth]

Hi — #7290 rebases the same one-line fix on current master and adds \ est/app.logerror.js. If you'd like to land this via #6464 instead, I'm happy to close #7290 or push the test commit to your branch. Thanks for opening the original fix!

[danizavtz]

It looks like there is an collateral effect the main reason for not doing that is that accidentally a sensible data can be logged.
I this case the data:

• host: '127.0.0.1',
  

• port: 5432
  

can be sensible, in this example it is an acceptable value but in production environment this same data can be sensible.

In libs like 'pg' the only field that does not have sensible data (and can be logged) without problem, is the field "detail" as per documentation.

Here I am only looking to one lib.