logger.arm() does not work on server

[arggh]

Calling logger.arm() on the server does not seem to work as described in README.

Both client and server applications may capture exception stack traces and log them for plain errors (window.onerror handling) and exception reporting. This is triggers by the logger.arm() method, and can be disabled by the logger.disarm() method.

Example

/server/main.js

import { MongodbSender, ServerLogger, LeveledStrategy, MeteorUserProcessor } from 'filog';

// Initialize FiLog logger
const sender = new MongodbSender(Mongo, 'logger');
logger = new ServerLogger(
  new LeveledStrategy(sender, sender, sender),
  WebApp);
logger.processors.push(new MeteorUserProcessor());
logger.arm();

/server/some/other/directory/file.js

callNonExistentFunction();

This does not produce a log entry in the MongoDB's collection logger, instead, it just logs to console. The same procedure on the client does produce a log entry.

[fgm]

Confirmed: this was planned, but in its current implementation relying on csnover/TraceKit, the stacks are only captured on browsers. The alternative, occ/TraceKit, rejected including Node support too.

Looking into https://github.com/v8/v8/wiki/Stack%20Trace%20API to see what it would entail. If you have any idea, I'm all ears.

[fgm]

So I did various tests on the server side and it is indeed simple to make arm() work for top-level code by listening to the uncaughtException Error event. However:

• this means we catch situations where there is no real way to know if continuing makes any sense. I think arm() could take an optional exit code parameter and set process.exitCode if it is not null, allowing exit as soon as all callbacks - including the logging action itself - are over.
• Meteor creates new execution contexts where it catches "uncaught" exceptions itself and exits: see how timers.js#bindAndCatch() used Meteor.bindEnvironment(), and is used by Meteor.setTimeout(), Meteor.setInterval(), and Meteor.defer(). In such cases the error does not bubble up to the logger as Meteor silences the exception by just reporting on it and continuing. Monkey-patching this would be quite fragile.

Any idea ?

[fgm]

Interesting and possibly useful article about errors: https://airbrake.io/blog/javascript-error-handling/javascript-error-hierarchy