captureException() fails with HTTP Status Code 413

[arabold]

I'm browserify & minify my code base into a single huge JS with just a few lines of code (but many, many characters per line obviously). While the code itself works fine, it fails to upload any captured exception to getsentry.com with HTTP Status Code 413.

I could nail it down to the minification. If I'm running the unminified version (still one huge JS file, but this time with many lines of code) then POSTing the exception works as expected. I'm guessing that the reason is that Raven tries to submit callstack information and gets thrown off by the fact that pretty much everything is in a single line of code.

In an ideal world I want to upload my source map to Sentry and have Raven-Node/Sentry figure the rest out. Or maybe I should use raven-js instead of raven-node although I'm running server-side?

[mattrobenolt]

That's definitely the problem. We also don't even support source maps for node. That's exclusively a browser JavaScript feature for us now.

Since this is a bit confusing to me, can you share some context on why you'd do this for a Node deployment in the first place?

[arabold]

https://github.com/arabold/serverless-sentry-plugin -- this is why :)

We're developing projects for AWS Lambda using the popular Serverless framework. For AWS Lambda it is common to browserify and minify the code base as it improves loading time. The link above is for a plugin that automatically instructs your code to report errors to Sentry.

[scottgeye]

Running into the same issue. Any update or work around for this?

Thanks!

[sid137]

just got bit by this too... 4 hrs of life...

[LewisJEllis]

@sid137 sorry to hear that :(

I'll look into this more today, especially since it seems we'll have more folks with long single lines of source after the recent webpack compatibility workaround in v2.0.0 and the generally increasing popularity of lambda.

Sourcemap support is a relevant topic here, and it's on the roadmap, but it's definitely a bigger undertaking and we don't consider it to be quite as crucial of a feature as it is in the browser, for a number of reasons. A fix for the 413 problem specifically should be pretty straightforward, hopefully just a "if line longer than x, truncate" check.

[kamilogorek]

Fixed in 8e111ff#diff-50e3aa130a4f97a42ee2cf111c7b1d9d

Also confirmed that stack size for raw express.js app, bundled with browserify and uglifyjs is below 50kb, which fits easily into payload limit.