getsentry/raven-node

A standalone (Node.js) client for Sentry

We are in the process of unifying all our JavaScript based SDKs. Because of that, raven-node has been moved into the main Sentry JS SDK mono-repo and this repo has been archived.

Please report any issues and requests there, as this repo is read-only.

---

Raven-node - Sentry SDK for Node.js

raven-node supports only LTS versions of Node, therefore currently required release is >= v4.0.0. The last known working version for v0.10 and v0.12 is [email protected]. Please use this version if you need to support those releases of Node.

To see up-to-date Node.js LTS Release Schedule, go to https://github.com/nodejs/LTS.

Resources

• Documentation
• Bug Tracker
• IRC (chat.freenode.net, #sentry)

raven-node's Issues

Incompatibility with node-newrelic

This error is throw when I use raven-node and newrelic TypeError: Cannot read property 'accept-encoding' of undefined.

raven-node use raw-stacktrace to have a detailed stack trace with this code :

traces.on("trace", function(err, callsites) {
    err.structuredStackTrace = callsites;
});

And this create a problem in bunyan module use by newrelic line 685 :

str = JSON.stringify(obj, safeCycles()) + '\n';

It can no longer serialize errors because it can not serialize structuredStackTrace property.

Here a sample of code to produce the bug :

var newrelic = require('newrelic');
    raven = require('raven'),
    express = require('express'),
    app = express(),
    ravenClient = new raven.Client();

app.get('/error', function(req, res){
  throw new Error();
});

app.listen(3000);

And the package.json

{
  "dependencies": {
    "express": "~3.4.7",
    "newrelic": "~1.1.1",
    "raven": "~0.6.0"
  }
}

Run and go to http://localhost:3000/error

Send additional error information

In node, it is not uncommon for errors to have properties beyond name, message, and stack. A good example of this is AssertionErrors which have actual, expected, and operator properties.

https://github.com/joyent/node/blob/v0.11.12/lib/assert.js#L41-L44

It would be nice if we were to expose these extra properties of an error object to extra (or some other location). Do you think this would be possible and should they occupy a namespace inside of extra (e.g. extra.errorProperties)?

Caught exception: Error: bind EMFILE

I was load testing my service and started getting these EMFILE errors.

Caught exception: Error: bind EMFILE
  at errnoException (dgram.js:454:11)
  at dgram.js:207:28
  at dns.js:72:18
  at process._tickCallback (node.js:415:13)

I saw the total number of files go up and down until it reached 1024 and started throwing these errors.

Commenting out raven usage, this dropped to a stable oscillation between 12 to 23 open FD.

Raven usage: https://github.com/mozilla/apk-factory-service/blob/31d2b9d0bcfaf7b6d072b071615ffa228f6b2f8d/lib/logging.js#L14

var raven = require('raven');
var sentry;

...
sentry = new raven.Client(config.sentryDSN);

...
winston.add(Sentry, {
      timestamp: function() {
        return new Date().toISOString();
      },
      level: config.logLevel,
    });

...
function Sentry(options) {
  this.name = 'sentryLogger';
  this.level = options.level || 'info';
}
util.inherits(Sentry, winston.Transport);

var winstonLevel = {
  warn: 'warning'
};

Sentry.prototype.log = function(level, msg, meta, cb) {
  var opts = {
    level: winstonLevel[level] || level
  };
  sentry.captureMessage(msg, opts);
  cb(null, true);
};

The above code snippet can be seen in context via that link.

Anything obviously wrong with the usage of raven?

Disable Sentry entirely with a "falsey" DSN

See: #13

Raven crashes when parsing template error

We are using eco which produces errors in non-traceback format, as in:

Parse error on line 14: unexpected dedent

Result of that is whole application crashing with

TypeError: Cannot call method 'split' of undefined
at Object.parseStack (/Users/jakub/Documents/apiary/node_modules/raven/lib/utils.js:103:23)
at Object.parseError (/Users/jakub/Documents/apiary/node_modules/raven/lib/parsers.js:15:11)
at Client.captureError (/Users/jakub/Documents/apiary/node_modules/raven/lib/client.js:134:13)
at Object.<anonymous> (/Users/jakub/Documents/apiary/node_modules/raven/lib/middleware/connect.js:8:16)
at Object.handle (/Users/jakub/Documents/apiary/node_modules/express/lib/http.js:192:10)
at IncomingMessage.next (/Users/jakub/Documents/apiary/node_modules/express/node_modules/connect/lib/http.js:198:17)
at ServerResponse.render (/Users/jakub/Documents/apiary/node_modules/express/lib/view.js:328:16)
at Promise.<anonymous> (/Users/jakub/Documents/apiary/lib/docs.coffee:319:28)
at Promise.<anonymous> (/Users/jakub/Documents/apiary/node_modules/mongoose/lib/promise.js:120:8)
at Promise.<anonymous> (events.js:67:17)

UDP Transport

• Restructure to have pluggable transports
• UDP Transport

Drop node 0.6 support

Does anybody care about this still? By dropping support, I mean, I'd remove automated tests from being run against 0.6. I assume things will continue to work, but I won't be aware of something does break it.

It's causing the build to fail on Travis and I don't personally care to try and fix it.

See: https://travis-ci.org/getsentry/raven-node/jobs/42419289

captureError sends malformed data to sentry if called with a string

When calling captureError with a string instead of an Error type, the "Sentry (Internal)" project logs an error with "Client 'raven-node/0.4.1' raised API error:" and no other data.

As discussed in IRC, a check for instanceof Error could dispatch to captureMessage to avoid this issue.

There is no way to provide a custom SSL certificat for HTTPS

Hi there,

I'm trying to use raven using an HTTPS DSN with a self signed certificate. So, I'm getting a SELF_SIGNED_CERT_IN_CHAIN error when I try to emit messages to sentry.

Is there a way to add ca field to requests options ? http://nodejs.org/api/https.html#https_https_request_options_callback

I can try to make a PR but not sure about how to correctly give the arguments to the transport.send() method

Thanks !

constructChecksum should consider level

I think if one send 2 event with the same message, but one of them is a fatal error and another is just an info message with level=info sentry should display them as different events and not group then. Therefore raven have to use level too for calculating the checksum.

TypeError: Cannot read property 'paths' of undefined

I can't find anyone else having this problem, but I got it immediately and can't seem to get around it.

➜  ~   mkdir ~/project
➜  ~   cd ~/project
➜  project   npm install raven
npm http GET https://registry.npmjs.org/raven
npm http 304 https://registry.npmjs.org/raven
npm http GET https://registry.npmjs.org/node-uuid
npm http GET https://registry.npmjs.org/stack-trace/0.0.7
npm http GET https://registry.npmjs.org/cookie/0.1.0
npm http 304 https://registry.npmjs.org/cookie/0.1.0
npm http 304 https://registry.npmjs.org/node-uuid
npm http 304 https://registry.npmjs.org/stack-trace/0.0.7
[email protected] ../node_modules/raven
├── [email protected]
├── [email protected]
└── [email protected]
➜  project   node
> var raven = require('raven');
TypeError: Cannot read property 'paths' of undefined
    at Object.<anonymous> (/Users/cburt/node_modules/lsmod/index.js:12:30)
    at Module._compile (module.js:449:26)
    at Object.Module._extensions..js (module.js:467:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:362:17)
    at require (module.js:378:17)
    at Object.<anonymous> (/Users/cburt/node_modules/raven/lib/utils.js:6:13)
    at Module._compile (module.js:449:26)
    at Object.Module._extensions..js (module.js:467:10)```

Additional APIs / improvements to parsing

Currently it's actually pretty messy to add a contextual description to an error, or add parsed request info to messages or errors outside of the middleware.

function someView(req, res) {
  doStuff(function(err, data) {
    if (err) {
      parsers.parseError(err, parsers.parseRequest(req), function(kwargs) {
        var result = client.captureMessage("error/context description", kwargs);
        res.send(400, "Badness: " + client.getIdent(result));
      });
    } else {
      res.send(200, data);
    }
  }
}

Seems we could make it a lot simpler pretty easily:

1. add an optional description to captureError():

client.captureError(Error error[, String description][, Object options][, Function callback])

1. automatically look for a request (or req) in any options passed to captureMessage() and captureError(). If found, run parseRequest() on it.

The above then becomes

function someView(req, res) {
  doStuff(function(err, data) {
    if (err) {
      client.captureError(err, "context description", {request: req}, function(result) {
        res.send(400, "Badness: " + client.getIdent(result));
      });
    } else {
      res.send(200, data);
    }
  }
}

and passing request information along with a captureMessage() call becomes:

client.captureMessage("some message", {request:req});

Thoughts on the concept?

Raven crashes more than my app does.

When it crashes it produces the following error:

/home/pi/stalker/node_modules/raven/lib/utils.js:96
stack.forEach(function(line, index) {
^
TypeError: Object Error: getaddrinfo ENOTFOUND
at errnoException (dns.js:37:11)
at Object.onanswer as oncomplete has no method 'forEach'
at Object.parseStack (/home/pi/stalker/node_modules/raven/lib/utils.js:96:11)
at Object.parseError (/home/pi/stalker/node_modules/raven/lib/parsers.js:20:11)
at Client.captureError (/home/pi/stalker/node_modules/raven/lib/client.js:124:13)
at process. (/home/pi/stalker/node_modules/raven/lib/client.js:167:16)
at process.EventEmitter.emit (events.js:95:17)
at process._fatalException (node.js:272:26)
Forever detected script exited with code: 7

pass original exception to patchGlobal callback

Thant means:

 process.on('uncaughtException', function(err) {
        if(cb) {  // bind event listeners only if a callback was supplied
            client.once('logged', function() {
                cb(true, err);
            });
            client.once('error', function() {
                cb(false, err);
            });
        }
        client.captureError(err, function(result) {
            node_util.log('uncaughtException: '+client.getIdent(result));
        });
    });

So we can do:

    client.patchGlobal(function(status, err) {
      console.error('wow~~ something is broken!');
      console.trace(err);
      process.exit(1);
    });

The uncaught exception will be outputted to stderr, instead of vanishing in sentry request sending.

Useful for local debugging.

Crashes with 'use strict' declaration

See #40

Ignore undefined values

As a suggestion, It think it would be a nice feature that the function captureError and family would ignore the undefined or null values. It would allow to make a cleaner use of the client.

Right now it's impossible to call the function directly like this:

functionWithCallback(a,b,c, client.captureError);

And force the use of an additional functions:

functionWithCallback(a,b,c, function(e){ if(e) client.captureError(e); });

Regards,
Bruno

HTTP Error (400): Client/server version mismatch: Unsupported protocol version (5)

Hello,

When I use the versions 0.7.x, on the log error, happen the error bellow:

HTTP Error (400): Client/server version mismatch: Unsupported protocol version (5)

But when I use the version 0.6.3, it's works!

Why?

Thanks!

Unbelievably, raven's require-call must be separate from the Client construction

So, the following works as expected (copied from your README):

var raven = require('raven');
var client = new raven.Client('{{ SENTRY_DSN }}');

client.captureMessage('Hello, world!');

… but as soon as I change it to the following …

var client = new require('raven').Client('{{ SENTRY_DSN }}');

client.captureMessage('Hello, world!');

… I get this:

/Users/ELLIOTTCABLE/Desktop/raven-test/node_modules/raven/lib/client.js:38
    this.on('error', function(e) {});  // noop
         ^
TypeError: Object #<Object> has no method 'on'
    at Object.Client (/Users/ELLIOTTCABLE/Desktop/raven-test/node_modules/raven/lib/client.js:38:10)
    at Object.<anonymous> (/Users/ELLIOTTCABLE/Desktop/raven-test/index.js:1:97)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)
    at startup (node.js:119:16)
    at node.js:902:3

I thought I knew quite a bit about JavaScript, but this one has me straight-up bumfuzzled. How on earth could that small, synchronous change affect whether or not inherits has processed? Something here is way, way beyond me.

Not exactly a world-shattering bug, but certainly one that's mildly annoying for my coding-style. /=

Support for Interfaces

Is there support for interfaces in this library? I havent found any documentation, for example id like to use the "User" interface to send details along with every error triggered from patchGlobal

https://sentry.readthedocs.org/en/latest/developer/interfaces/index.html

patchGlobal() doesn't re-raise exceptions

This might very well be a feature so I might need to implement this myself in my application, but I'm not really sure how to approach it.
Basically, patchGlobal() will capture uncaught exceptions and send them to Sentry. From nodejs documentation (http://nodejs.org/api/process.html#process_event_uncaughtexception ):

If you do use it, restart your application after every unhandled exception!

So not quitting the process after this, can potentially leave the application in an unstable state. I've tried to wait for the captureError callback to do process.exit(1);, but I couldn't consistently make sure the exception was received by Sentry.

Am I missing something here? I feel like there's an easy way of solving this, but I just can't think of any.

Does raven-node always need NODE_ENV to be production?

I'm testing Sentry for a new app (still in development mode), and not seeing any events on getsentry.com

But I'm not seeing any reference of NODE_ENV in the source code.

Cannot initialize Client: TypeError: Object #<Object> has no method 'on'

I'm stuck at the begining …

var raven = require('raven');
var client = raven.Client('{{ DSN goes here}}');

results in:

TypeError: Object #<Object> has no method 'on'
    at Object.Client (/home/djensen/src/road-rules-mqtt-manta/node_modules/raven/lib/client.js:38:10)
    at repl:1:7
    at REPLServer.self.eval (repl.js:110:21)
    at repl.js:249:20
    at REPLServer.self.eval (repl.js:122:7)
    at Interface.<anonymous> (repl.js:239:12)
    at Interface.emit (events.js:95:17)
    at Interface._onLine (readline.js:202:10)
    at Interface._line (readline.js:531:8)
    at Interface._ttyWrite (readline.js:760:14)
    at ReadStream.onkeypress (readline.js:99:10)
    at ReadStream.emit (events.js:98:17)
    at emitKey (readline.js:1095:12)
    at ReadStream.onData (readline.js:840:14)
    at ReadStream.emit (events.js:95:17)
    at ReadStream.<anonymous> (_stream_readable.js:764:14)
    at ReadStream.emit (events.js:92:17)
    at emitReadable_ (_stream_readable.js:426:10)
    at emitReadable (_stream_readable.js:422:5)
    at readableAddChunk (_stream_readable.js:165:9)
    at ReadStream.Readable.push (_stream_readable.js:127:10)
    at TTY.onread (net.js:528:21)

Thrown errors not logged in express

Hi,

Currently in the works of setting up a Node.JS application using Express.JS and Sentry for error logging. However, only uncaught errors seams to be logged if I use client.patchGlobal() otherwise thrown errors are only printed to the command line and Sentry never gets them. Yes, I run the server in production mode.

Tested on:
Node.JS: v0.8.19
Express.JS: v3.1.0
raven-node: v0.4.6

Express deprecation warning for `req.host`

express deprecated req.host: Use req.hostname instead node_modules/raven/lib/parsers.js:84:19

Messages are showing up in the log for Express 4.9.5.

If I get around to it, I'll cook up a trivial PR and give it some testing love.

Cheers!

Traceback error using CoffeeScript > 1.6.1

CoffeeScript now modifies Error.prepareStackTrace and the Traceback module doesn't like that.

That's too bad since the new stack traces show the line numbers for both CS and JS. For now, I've reverted back to 1.6.1, but I intend on coming back to fix this.

Limit private data being sent

Hello,

Raven sends awfully lot of requests' private data (and thereby private data of people) to Sentry, which frankly it mustn't.

Fortunately reimplementing the Connect middleware is not too difficult, but there are bits of data gathering that are not possible to overwrite without changing the source. LINES_OF_CONTEXT that grabs the contents of the source files is one of those bits. If anything, that should be set as a property in some Raven object that would make it possible to disable source sending entirely.

Implement processors/sanitization API

Be able to select log level

version bump and publish

Can you publish v0.6.3 ?

Sentry dies when node_modules directory doesn't exist

I have a directory structure like:

node_modules/
cornfield/app.js

When using sentry, it dies with the following error:

fs.js:500
  return binding.readdir(pathModule._makeLong(path));
                 ^
Error: ENOENT, no such file or directory '/Users/jon/Dropbox/Sites/butter/dist/cornfield/node_modules/'
    at Object.fs.readdirSync (fs.js:500:18)
    at Object.getModules (/Users/jon/Dropbox/Sites/butter/dist/node_modules/raven/lib/utils.js:72:22)
    at Client.process (/Users/jon/Dropbox/Sites/butter/dist/node_modules/raven/lib/client.js:54:31)
    at _.captureError._.captureException (/Users/jon/Dropbox/Sites/butter/dist/node_modules/raven/lib/client.js:123:27)
    at module.exports.parseError (/Users/jon/Dropbox/Sites/butter/dist/node_modules/raven/lib/parsers.js:31:9)
    at module.exports.parseStack.lines.forEach.frames.(anonymous function) (/Users/jon/Dropbox/Sites/butter/dist/node_modules/raven/lib/utils.js:126:47)
    at fs.readFile (fs.js:176:14)
    at Object.oncomplete (fs.js:297:15)

This is because it's looking for a node_modules directory at the same level as cornfield/app.js.

Handle http 429?

I came here to get ideas about how you handle the promised (threatened?) HTTP 429 for throttling. Was surprised not to find it anywhere in the code base, seems >299 is treated as an error. Thoughts on maybe doing a warning or wait and retry?

grouping messages and additional data

Hi,

If we add user information like userId to the message of the error, event will never be grouped, because of different ids, so I started to write common messages and pass additional data like userId in 2. parameter of .captureError or .captureMessage. It works fine, the only problem is sentry interface doesn't displays this data, so I need to look for it in "RAW JSON Data", this is not very convinent. Is there any way to push additional data object to sentry, which will be nicely displayed?

Best,
Oleg

Implement context methods

We need to add the various context mechanisms to Node:

• user_context
• tags_context
• extra_context
• http_context

See the PHP client for some implementation examples:

https://github.com/getsentry/raven-php#providing-request-context

https://github.com/getsentry/raven-php/blob/master/lib/Raven/Context.php

Add an option to disable process.env capture

Need to give some consideration to how this might look/work, and how we might carry this over to other platforms. I almost feel like we should have an option for every property we capture

captureX() methods should call their callbacks after data has been successfully logged

The methods captureError, captureMessage and captureQuery call their callbacks to early: https://github.com/getsentry/raven-node/blob/master/lib/client.js#L128

In my code I use error domains to capture errors:

var d = domain.create();

domain.run(function(){
  // code that throws errors
});

However if I use the captureException method, the events do not arrive at getsentry:

domain.on('error', function(){
  sentry.captureException(err, function(){
    process.exit(1);
  });
});

The process.exit call will terminate the process to early. I think the behaviour of these methods should be similar to patchGlobal which calls its callback when the client emits the logged event.

Am I right, or did I miss something?

Same object in different interfaces ignored

Hey,

The circular dependency checking code in client.js is a little naíve and strips every duplicate object. Not to mention it's rather inefficient. It really should ignore only circular dependencies, not merely objects appearing twice in two different places. Just spent some wtfs trying to figure out why headers in the HTTP interface were ignored. They were intentionally both on the error object and the HTTP interface.

Provide way to attach user information when capturing

It's useful to know which user and how many users caused an error, especially because Sentry can turn that information into a useful metric.

The problem in node is that there exists no concept of "the current user". It makes no sense.

It's already possible to attach user info when capturing an error:

client.captureError(error, {
  'sentry.interfaces.User': {
    id: 'foobar'
  }
});

It wouldn't make much sense to provide a client.setUser method like in raven-js. The client is probably shared among different requests with separate users. So I suggest adding a shorthand for this:

client.captureError(error, {
  user: {
    id: 'foobar'
  }
});

Another idea was allowing something like this:

var userClient = client.forUser(currentUser);

// Somewhere else
userClient.captureError(error); // <--- includes user information

./lib/middleware/connect.js invokes next() too early

I'm having some trouble, my software has a crash-only approach and I've defined the following express.js (3.x) middlewares:

app.use(raven.middleware.express('DSN'));
app.use(function(error, req, res, next){ 
        console.log('-> * Crashing!', res.sentry);  
        res.send(500);
        process.exit(-1);
});

But although the next() method is called on the clientError callback (./lib/middleware/connect.js) my sentry dashboard does not show the new event.

When I deploy a 2 second timeout on the process.exit(-1), then the event gets to sentry.

I believe that the notification request (to the sentry server) is issued but the callback is invoked before the request is finished, would you be so kind to offer some assistance on this matter?

Crash on capturing mangled stack traces (from q promises library)

When I call client.captureError on an error, raven.js crashes and crashes my entire app, and never logs anything to the server. We are using node 0.10x and the Q library for promises.

Here's the code I'm using to setup and call raven. It looks like patchGlobal isn't doing anything because it never logs or exits properly.

var client = new raven.Client(config_capture.sentryDSN);
client.patchGlobal(function() {
  console.log('Uncaught exception, restarting server...');
  process.exit(1);
});

// in a Q promise block chain, this is the error handler
function(error){
    console.log('Q propogated error: /upload/:up_token/:uid');
    console.log(error);
    if (typeof error != 'undefined') {
      client.captureError(error);
    }
  }

Here is the full crash log that is printed to the console:

[TypeError: Cannot call method 'apply' of undefined]

/Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/node_modules/raven/lib/utils.js:96
    stack.forEach(function(line, index) {
          ^
TypeError: Object TypeError: Object TypeError: Cannot call method 'apply' of undefined
    at /Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/node_modules/q/q.js:1044:28
From previous event:
    at app.post.Q.fcall.then.updateRecording.all_files (/Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/server.js:273:4)
    at callbacks (/Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/node_modules/express/lib/router/index.js:161:37)
    at param (/Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/node_modules/express/lib/router/index.js:135:11)
    at param (/Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/node_modules/express/lib/router/index.js:132:11)
    at param (/Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/node_modules/express/lib/router/index.js:132:11)
    at pass (/Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/node_modules/express/lib/router/index.js:142:5)
    at Router._dispatch (/Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/node_modules/express/lib/router/index.js:170:5)
    at Object.router (/Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/node_modules/express/lib/router/index.js:33:10)
    at next (/Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/node_modules/express/node_modules/connect/lib/proto.js:199:15)
    at Object.expressValidator [as handle] (/Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/node_modules/express-validator/lib/express_validator.js:140:10)
    at next (/Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/node_modules/express/node_modules/connect/lib/proto.js:199:15)
    at IncomingForm.<anonymous> (/Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/node_modules/express/node_modules/connect/lib/middleware/multipart.js:119:31)
    at IncomingForm.EventEmitter.emit (events.js:92:17)
    at IncomingForm._maybeEnd (/Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/node_modules/formidable/lib/incoming_form.js:383:8)
    at /Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/node_modules/formidable/lib/incoming_form.js:212:12
    at WriteStream.<anonymous> (/Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/node_modules/formidable/lib/file.js:71:5)
    at WriteStream.g (events.js:175:14)
    at WriteStream.EventEmitter.emit (events.js:117:20)
    at finishMaybe (_stream_writable.js:335:12)
    at onwrite (_stream_writable.js:243:20)
    at WritableState.onwrite (_stream_writable.js:92:5)
    at fs.js:1681:5
    at Object.wrapper [as oncomplete] (fs.js:510:5) has no method 'forEach'
    at Object.parseStack (/Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/node_modules/raven/lib/utils.js:96:11)
    at Object.parseError (/Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/node_modules/raven/lib/parsers.js:20:11)
    at Client.captureError (/Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/node_modules/raven/lib/client.js:124:13)
    at /Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/server.js:292:14
    at _rejected (/Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/node_modules/q/q.js:840:24)
    at /Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/node_modules/q/q.js:867:30
    at makePromise.when (/Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/node_modules/q/q.js:649:31)
    at makePromise.promise.promiseSend (/Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/node_modules/q/q.js:479:41)
    at /Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/node_modules/q/q.js:388:35
    at process._tickCallback (node.js:415:13) has no method 'forEach'
    at Object.parseStack (/Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/node_modules/raven/lib/utils.js:96:11)
    at Object.parseError (/Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/node_modules/raven/lib/parsers.js:20:11)
    at Client.captureError (/Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/node_modules/raven/lib/client.js:124:13)
    at process.<anonymous> (/Users/chrisbal/Documents/OpenWatch/NodeMediaCapture/node_modules/raven/lib/client.js:167:16)
    at process.EventEmitter.emit (events.js:95:17)
    at process._fatalException (node.js:272:26)

Non-production environment best practices?

What is the intended usage outside production environment? This line seems to imply that it should not be run - but it's kind of awkward to make a special if/then code branch that does not require/instantialize raven.

Could I get an init option that says "don't report disabled" or "be disabled"?

Pinging tags

Is it possible to ping tags using raven-node?

I've tried

client.captureMessage("hello tags", {
  tags: {
    env: "staging"
  }
});

and

var data = {};
data["sentry.interfaces.Http"] = {};
data["sentry.interfaces.Http"]["tags"] = {
  env: "staging"
}
client.captureMessage("hello tags", data);

send callback

hi

1. captureMessage, captureError etc. callbacks should be fired after the message is delivered
2. sendRemote ignores errros, which actualy should be passed to the callback. Please pass the error object also if emiting error on client instance self.emit('error', err);

If I want to log something and then exit the process, I need this send callback, otherwise I have to do ugly setTimeout for some time to ensure the message was sent.

Publish new version

There have been a lot of changes since 0.6.0. It would be nice if there was a new version published with these changes. The alternative of git URL + sha works but it not as ideal.

Error: Uncaught, unspecified 'error' event.

Hi,
I've been using Raven for a project and I haven't had any issues during development.
When deploying it to Heroku, and after parsing a csv file using node-csv-parser the following error is displayed (and the server is restarted):

events.js:73
throw new Error("Uncaught, unspecified 'error' event.");
^
Error: Uncaught, unspecified 'error' event.
at Client.EventEmitter.emit (events.js:73:15)
at IncomingMessage.HTTPTransport.send (/app/node_modules/raven/lib/transports.js:31:22)
at IncomingMessage.EventEmitter.emit (events.js:126:20)
at IncomingMessage._emitEnd (http.js:366:10)
at HTTPParser.parserOnMessageComplete as onMessageComplete
at CleartextStream.socketOnData as ondata
at CleartextStream.CryptoStream._push (tls.js:526:27)
at SecurePair.cycle (tls.js:880:20)
at EncryptedStream.CryptoStream.write (tls.js:267:13)
at Socket.ondata (stream.js:38:26)

Can you please advise?

Thanks in advance

Be able to log into console in development mode

It would be useful if I could still see captured messages/errors when developing.

It would be useful to just send messages to console.error. Maybe, to prevent regression, this could be done when SENTRY_LOG_TO_CONSOLE env var is set.

Bring up to date with latest Sentry/Raven

A running list of things to update/change:

• Drop request signatures

New master version of Raven is kind of borked

If I use the latest master version of raven-node, I get:

Blahblahdir\node_modules\raven\lib\utils.js:93
line.getTypeName() + '.' + (line.getMethodName() || '');
^
[object Arguments]

When running "client.captureError(new Error("Could not connect to server over Tor."));".

Node v.10 support

I'm not sure if there are any issues, but the README only mentions support to 0.9

Running Raven in other environments than production

I have several other environments than NODE_ENV == 'production' that I would like to run Raven in. For example our staging environment.

Can we perhaps add a setting that allows you to run Raven regardless of the NODE_ENV?

(Also, running my app in the production environment locally to test Raven is a pain in the ass. Production is configured to connect to all kinds of clusters and other services. It would help a lot if the app itself could determine when and how to use Raven instead of Raven itself.)

Sentry runs when NODE_ENV is 'test'

When we run our test cases locally, we run with NODE_ENV=test. It looks like sentry is enabled when NODE_ENV is 'test' or 'production', despite the documentation saying "NODE_ENV must be set to production for Sentry to actually work".

This is causing sentry to trigger errors while we're running local test cases.