Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't send invalid data and parse more stack traces. #11

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

hesselink
Copy link
Contributor

This pull requests includes two sets of changes. The first makes sure the data sent to the squash backend is always valid. Previously the javascript client could send data the wasn't accepted by the backend, causing failed requests and errors that were not reported.

The second allows tracekit to parse stack traces from javascript served from https urls.

I've made it one pull request; let me know if you prefer two separate ones.

hesselink and others added 5 commits May 23, 2013 12:19
The Squash server does validation and crashes if the fields don't validate. This way we at least get some data in the system.
The Squash server doesn't allow this; this way, we get some data in the system.
The Squash server doesn't allow occurrences without any backtrace lines. This way we get at least some data.
# The server doesn't allow empty backtraces. We fake one to
# make sure the error arrives anyway.
if backtraces.length == 0
backtraces.push {url: "fake", line: 1, symbol: "", type: 'minified'}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's your intention to send fake backtraces to Squash? I would either be of the opinion that a) we should not send an exception if we can't determine the stack trace, or b) we should use a custom type indicating the situation so that Squash doesn't process and display a file named "fake", but instead properly displays the situation (no backtrace could be determined).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I want to send a 'fake' backtrace, since there is still useful info in the top level error object, and I'm also attaching useful user data (like the unparsed backtrace, since there's so many bugs in the client side parsing). I'm also fine with allowing errors without backtraces: I ran into the same problem when writing a Haskell client. I'm not the biggest Ruby hero though, and Rails, well, that's another thing entirely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants