15 ms·

Show HN: RootCause – Record, Replay and Reproduce JavaScript Errors

98 points by mankz 8y ago

ggregoire 8y ago
Not directly related to this product (looks good btw!), but I've been using static type checking (Flow/TypeScript) for almost 2 years and since then, I haven't seen a single JS error in production. I do believe it's as important as writing tests now, if not more.
- TheAceOfHearts 8y ago
  Do you have client-side error logging setup? I find it very hard to believe you wouldn't encounter any browser bugs, or bugs due to external applications fucking around with the browser. To give an example, I've seen lots of "antiviruses" inject code or perform unexpected DOM changes, causing certain things to break. Other times a user shows up with a heavily tweaked browsers that behaves differently from what you'd expect.
  - ggregoire 8y ago
    Yes with Sentry. Also I don't make websites but b2b applications and I can so target the last browsers versions and most of our users don't try to tweak stuff.
  - vtange 8y ago
    What sort of "antiviruses" inject stuff in browsers? Do they inject their own JS? This is the first I've heard of this and would like to know more.
    - scrollaway 8y ago
      Shitty browser extensions mostly. It's like 99% of our sentry errors as well.
    - TheAceOfHearts 8y ago
      I don't remember which vendors were causing it, but yes, many inject their own JS, causing things to break and exceptions to be thrown. Here's a StackExchange question: "How to disable Kaspersky Antivirus javascript injection?" [0]. And on Reddit: "PSA: Kaspersky injects remote javascript into all your pages. Even secure ones." [1]. [0] https://superuser.com/questions/981959/how-to-disable-kaspersky-antivirus-javascript-injection https://superuser.com/questions/981959/how-to-disable-kasper... [1] https://www.reddit.com/r/privacy/comments/3frjqw/psa_kaspersky_injects_remote_javascript_into_all/ https://www.reddit.com/r/privacy/comments/3frjqw/psa_kaspers...
      - chairmankaga 8y ago
        Can also attest to this, had plenty of head-scratching issues before I realized on my home computer using kaspersky why our app was breaking.
- armandososa 8y ago
  that's impressive. What would you recommend between flow and typescript for an existing react app with an already large codebase?
  - RussianCow 8y ago
    I know React devs tend to gravitate towards Flow (which makes sense, since both are developed by Facebook), but I personally recommend TypeScript solely because it has a larger ecosystem and far more library type definitions. The actual type systems are pretty much identical these days, but having type definitions for almost every external library makes the out-of-the-box experience much, much better. Also, I found TypeScript very easy to integrate into an existing webpack setup, whereas I had a lot of trouble getting Flow to work seamlessly (though, apparently many others have had the opposite experience, so take that with a grain of salt).
  - Zalastax 8y ago
    TypeScript is ahead of Flow in both tooling and type expressiveness. Both can easily be added to an existing code base in incremental steps. I'd go for TypeScript every day of the week, but both are good choices.
  - ggregoire 8y ago
    I'm using Flow but I'd recommend TypeScript. I love Flow but TypeScript just seems to be more seriously maintained and less buggy. I've been waiting some bug fixes for 2 years (like all the object destructing and spread issues[1]), but they prioritize the Facebook private internal roadmap. I stick with Flow for now just because create-react-app doesn't support officially TypeScript, but it should be possible with the next major version that will include Babel 7. [1] https://github.com/facebook/flow/issues/2405 https://github.com/facebook/flow/issues/2405
- realharo 8y ago
  When you look at the screenshot on the product's homepage, 5 out of the 6 shown errors are things that TypeScript would have immediately caught.
TheAceOfHearts 8y ago
Unfortunately, site is down. For error tracking I've previously used Sentry [0]. I found it really easy to use and setup in a fairly large JS app. The best part is that it's open source, so you always have the option of hosting it yourself, which removes any fear of vendor lock-in. I'd say it's well worth paying for their SaaS offering. EDIT: Looking through the docs, it seems they expect you to load their non-versioned third-party sourced script, and it's not even hosted on a CDN. That's a huge security risk, so it's an immediate blacklist for me. [0] https://sentry.io/welcome/ https://sentry.io/welcome/
- ggregoire 8y ago
  The main difference here is that they track all the mouse moves and clicks so they can replay the user session right before the error happened.
  - TheAceOfHearts 8y ago
    Sentry tracks the last few events prior to the exception happening as well. You can't replay the actual interaction, but seeing the activity log has always been enough to meet my needs.
    - deleted 8y ago
      [deleted]
  - daniel_levine 8y ago
    Sentry does not offer that product natively, but they do have an integration with SessionStack to do it https://blog.sentry.io/2017/09/20/see-errors-through-users-eyes https://blog.sentry.io/2017/09/20/see-errors-through-users-e...
- mankz 8y ago
  RootCause offers all js-error logging features from Sentry/Sessionstack plus our Live Replay feature. We'll have a CDN up shortly, good point! You can also host the JS script yourself, or use the on-premises version (Docker image)
hknd 8y ago
Didn't think that I'll find an application in 2018 which will use ExtJS, but therootcause dashboard is using it (:
- mankz 8y ago
  Curious - why does it matter to you if the UI is built using Ext, Vue or React?
  - hknd 8y ago
    [disclaimer: I'm a java/js/... dev at a faang company, and I've used Ext before] Imho Ext is a specialty of all the existing UI frameworks, and imho it's shit. Tbh I though it would die directly after being bought by Idera. Even most of the most Senior people left or got fired after that. Most annoying things (imho): - lock in: all their widgets, and tooling, and everything only works for Sencha products, and is by far worse than the current open source counterparts - price: for a SMB/big-company this doesn't matter, but you pay a premium to use "widgets" which are worse (imho) than open source - Sencha Widgets compile into clunky and non-semantic HTML (thousands of divs), which also impacts performance a lot: simple apps usually have 3-5MB - debugging is difficult as you have to go through their "OOP" layers (can be 5-10 layers) [Java Developers created this Web Framework] People argue that it's great because many rich widgets are already available and because the framework tells you how do to stuff. But everyone will run into a point in time where something is just extremely hard because of extjs constraints, which usually ends in a hacky solution.
    - mankz 8y ago
      Sounds you had a very bad experience with Ext JS, but we hope you'll give RootCause a go anyway :)
      - hknd 8y ago
        Well, I'll definitely try it out. I don't make up my mind just because I don't like a technology personally.
bsimpson 8y ago
You'd want to be really careful recording/replaying sessions on pages that capture personally identifiable information; then again, you probably wouldn't be running a third-party service like this if you were.
- koolba 8y ago
  > ... then again, you probably wouldn't be running a third-party service like this if you were. While we'd like that to be true it's sadly not in practice. The most common example is websites with sensitive data in the URL (ex: PII query parameters) using third party analytics services that receive the entire URL as a metric.
- mankz 8y ago
  The RootCause API has multiple ways to scrub PII details from the session before posting it. And we also offer an on-premises version (Docker image) so that the data never leaves your own servers.
deleted 8y ago
[deleted]
nickreese 8y ago
Wow, this is impressively polished. Will look for an opportunity to test it out on a project we're working on.
k1ns 8y ago
This is great. Well done. The demo had me laughing in a very good way (I was genuinely having fun watching it replay).
hashkb 8y ago
Hugged to death. Wonder what they use for backend errors.
RussianCow 8y ago
Looks neat and particularly polished for a Show HN. I especially loved the sandbox demo. However, I don't see anything that this offers that LogRocket[0] doesn't already have. How does RootCause compare? [0]: https://logrocket.com/ https://logrocket.com/
- mankz 8y ago
  LogRocket is very neat looking but only does replay for Redux apps (as far as I know). We record all events for any web app so you can replay session and fire the exact same mouse+keyboard+ajax events to reproduce the issue. Very similar tools but we wanted to make something generic targeting every web app
  - RussianCow 8y ago
    I believe that's how they started, but that's no longer true of LogRocket—their service does not depend on Redux, though they offer a very nice integration with it if you happen to use it.
- jchook 8y ago
  I agree. Very polished. We use FullStory and it’s fantastic. Would be extremely difficult to convert me. https://www.fullstory.com/ https://www.fullstory.com/
  - saganus 8y ago
    Both LogRocket and FullStory are blocked by default by uMatrix. Any idea why?
    - willriker 8y ago
      I believe they are both classified as analytics tools which is why they are blocked. It's annoying that uMatrix will still block a tool even if you purposefully navigate to their site (versus if the tool is used for analytics on a different company's site).
igotsideas 8y ago
The site is down for me.
- mankz 8y ago
  Issue with GoDaddy load balancing :( We're on the phone with them now
  - mankz 8y ago
    Site back up :)
audiolion 8y ago
Looks like a direct competitor to https://sessionstack.io https://sessionstack.io I am not sure how I feel about these session recorders and probably want to start blocking them from my browser. It is akin to someone recording your every movement inside your house and watching the video to see what issues come up. Oh and you have no idea its happening. Also wonder about how this data is protected. If videos of how I used Facebook were leaked (messages I started to type but didnt send for instance) it would be a huge violation of my privacy. In the same token, its like free UX research, you can see where people struggle by watching them use the app. It is like standing over someone's shoulder to see how they are using the product and helps immensely in that realm. I still feel like it should be opt in though.
- mankz 8y ago
  Very valid points, great feedback and we completely agree, here's how we address this: 1. We recommend all our users to use the opt-in prompt before an error is logged. Demo: https://app.therootcause.io/sandbox/confirmation/ https://app.therootcause.io/sandbox/confirmation/ 2. We can also show a special icon in bottom right corner when video is recorded. Demo: https://app.therootcause.io/sandbox/videorecording/ https://app.therootcause.io/sandbox/videorecording/ And, it's not just about production sites - another use case is using this internally as a tool between QA <-> Developers to speed up communication when new errors are found.
kerkeslager 8y ago
The fact that tools like this are needed should be understood to mean that JavaScript error handling is fundamentally broken. In a reasonable language, you do something obviously wrong, and it throws an exception immediately, which gives you a stack trace that gives reasonable context for understanding what went wrong. In JavaScript, the failure often happens silently: "foo" + 1 returns "foo1", {}.foo returns undefined, and program execution continues until it absolutely can't, finally failing far away from where the problem occurred. And when it does fail, it often fails in a callback deep within framework code with no clear, traceable execution path that leads back to the point where the error occurred. The errors have all the mysteriousness of C errors, without even the traceability. The JavaScript community doesn't seem to be aware that there are better solutions, and seem happy with the way things are, even going so far as to use JavaScript on servers where far better tools exist. It seems that the only salvation that will come will be when mature tools exist on top of WebAssembly so that those of us who care about error reporting can use better toolchains.
- brlewis 8y ago
  You need a tool like this to monitor run-time browser errors. When browsers support a language that catches 100% of errors at compile time then you won't need tools like this. But I see what you're saying. Except for the declarative style popularized by React and also implemented in Mithril, Preact and Inferno, and except for the rise in popularity of TypeScript, and except for a lot of attention paid lately to immutable data structures, and except for jslint being created in 2002 and lots of similar tools since then, and except for the wide variety of JavaScript-based unit test frameworks, it really seems like the JavaScript community has no clue that there are ways to prevent the errors you describe and no inclination to prevent them.
  - kerkeslager 8y ago
    > You need a tool like this to monitor run-time browser errors. When browsers support a language that catches 100% of errors at compile time then you won't need tools like this. Eh, I don't think that logging runtime-in-the browser is the value added here. I can wrap my codebase in a try-catch that catches exceptions and calls home with the stack trace in < 100 lines of code. Avoiding that < 100 lines of code isn't the value added.
spraak 8y ago
I wonder why they didn't register https://www.rootcause.io/ https://www.rootcause.io/ (i.e. why the "the" in the url)
- mankz 8y ago
  Taken already
fiatjaf 8y ago
Unless you running a million-user app, I believe you shouldn't fall for this. I have, multiple times. I've tried to catch what users were doing and get a log of the exceptions they faced. Only despair followed from these attempts. The best error handling technique is to catch exceptions and show up a big popup on the screen with the error details. Your users will send those details to you instead of just saying "the app crashed".
- mankz 8y ago
  You sum it up well. If you just get static text (call stack etc) from your error logger tool, it's of almost no use as it doesn't reveal the state of the app. With modern tools that have replay capability, this changes and the debugging process is so much nicer. :)
  - Can_Not 8y ago
    Every error tracker I've ever used allows you to send arbitrary data (which could be your entire flux store, for example) and has great documentation on how to start using it.
    - mankz 8y ago
      We also allow you to attach any custom data to the error report. But this doesn't necessarily help you put the web application into the state where it crashes. Demo of custom data: https://app.therootcause.io/sandbox/addingcustomdata/ https://app.therootcause.io/sandbox/addingcustomdata/
- Can_Not 8y ago
  In my experience, users can't be bothered to copy and paste those errors. One feature of <literally any error tracker> is to give the user a code instead of the raw stack. This pairs well with the feature to attach arbitrary data (like current state, or atleast just user id), then you can see the whole error data in the tool on your own computer. I've been able to fix bugs before the support staff approaches me about it.
vbsteven 8y ago
I find it funny that here on HN in one thread we complain about Facebook scanning all of our messages while in the next thread we praise a product that tracks JavaScript events, keystrokes and mouse movements...
chacham15 8y ago
Random question: I've had bugs which were a simple result of timing (mostly due to the cpu being used by other processes running on the users machine), how would something like this be able to replay that error for me? If I were to replay that same data on my machine, because of the availability of cpu horsepower on my machine, I wouldnt be able to reproduce the error. Does anyone have insight to this?
- mankz 8y ago
  Race condition bugs are very tricky to reproduce indeed. While there will never be a guarantee our Live Replay will reproduce your issue - it should be possible since we replay all events in the exact sequence they were recorded. Our replay studio also has a 'Preserve timing' setting which uses the same delay between the events.
Annika11 8y ago
Nice!

98 points by mankz 8y ago

Not directly related to this product (looks good btw!), but I've been using static type checking (Flow/TypeScript) for almost 2 years and since then, I haven't seen a single JS error in production. I do believe it's as important as writing tests now, if not more.

TheAceOfHearts 8y ago
Do you have client-side error logging setup? I find it very hard to believe you wouldn't encounter any browser bugs, or bugs due to external applications fucking around with the browser. To give an example, I've seen lots of "antiviruses" inject code or perform unexpected DOM changes, causing certain things to break. Other times a user shows up with a heavily tweaked browsers that behaves differently from what you'd expect.
- ggregoire 8y ago
  Yes with Sentry. Also I don't make websites but b2b applications and I can so target the last browsers versions and most of our users don't try to tweak stuff.
- vtange 8y ago
  What sort of "antiviruses" inject stuff in browsers? Do they inject their own JS? This is the first I've heard of this and would like to know more.
  - scrollaway 8y ago
    Shitty browser extensions mostly. It's like 99% of our sentry errors as well.
  - TheAceOfHearts 8y ago
    I don't remember which vendors were causing it, but yes, many inject their own JS, causing things to break and exceptions to be thrown. Here's a StackExchange question: "How to disable Kaspersky Antivirus javascript injection?" [0]. And on Reddit: "PSA: Kaspersky injects remote javascript into all your pages. Even secure ones." [1]. [0] https://superuser.com/questions/981959/how-to-disable-kaspersky-antivirus-javascript-injection https://superuser.com/questions/981959/how-to-disable-kasper... [1] https://www.reddit.com/r/privacy/comments/3frjqw/psa_kaspersky_injects_remote_javascript_into_all/ https://www.reddit.com/r/privacy/comments/3frjqw/psa_kaspers...
    - chairmankaga 8y ago
      Can also attest to this, had plenty of head-scratching issues before I realized on my home computer using kaspersky why our app was breaking.
armandososa 8y ago
that's impressive. What would you recommend between flow and typescript for an existing react app with an already large codebase?
- RussianCow 8y ago
  I know React devs tend to gravitate towards Flow (which makes sense, since both are developed by Facebook), but I personally recommend TypeScript solely because it has a larger ecosystem and far more library type definitions. The actual type systems are pretty much identical these days, but having type definitions for almost every external library makes the out-of-the-box experience much, much better. Also, I found TypeScript very easy to integrate into an existing webpack setup, whereas I had a lot of trouble getting Flow to work seamlessly (though, apparently many others have had the opposite experience, so take that with a grain of salt).
- Zalastax 8y ago
  TypeScript is ahead of Flow in both tooling and type expressiveness. Both can easily be added to an existing code base in incremental steps. I'd go for TypeScript every day of the week, but both are good choices.
- ggregoire 8y ago
  I'm using Flow but I'd recommend TypeScript. I love Flow but TypeScript just seems to be more seriously maintained and less buggy. I've been waiting some bug fixes for 2 years (like all the object destructing and spread issues[1]), but they prioritize the Facebook private internal roadmap. I stick with Flow for now just because create-react-app doesn't support officially TypeScript, but it should be possible with the next major version that will include Babel 7. [1] https://github.com/facebook/flow/issues/2405 https://github.com/facebook/flow/issues/2405
realharo 8y ago
When you look at the screenshot on the product's homepage, 5 out of the 6 shown errors are things that TypeScript would have immediately caught.

TheAceOfHearts 8y ago

Unfortunately, site is down. For error tracking I've previously used Sentry [0]. I found it really easy to use and setup in a fairly large JS app. The best part is that it's open source, so you always have the option of hosting it yourself, which removes any fear of vendor lock-in. I'd say it's well worth paying for their SaaS offering. EDIT: Looking through the docs, it seems they expect you to load their non-versioned third-party sourced script, and it's not even hosted on a CDN. That's a huge security risk, so it's an immediate blacklist for me. [0] https://sentry.io/welcome/ https://sentry.io/welcome/

ggregoire 8y ago
The main difference here is that they track all the mouse moves and clicks so they can replay the user session right before the error happened.
- TheAceOfHearts 8y ago
  Sentry tracks the last few events prior to the exception happening as well. You can't replay the actual interaction, but seeing the activity log has always been enough to meet my needs.
  - deleted 8y ago
    [deleted]
- daniel_levine 8y ago
  Sentry does not offer that product natively, but they do have an integration with SessionStack to do it https://blog.sentry.io/2017/09/20/see-errors-through-users-eyes https://blog.sentry.io/2017/09/20/see-errors-through-users-e...
mankz 8y ago
RootCause offers all js-error logging features from Sentry/Sessionstack plus our Live Replay feature. We'll have a CDN up shortly, good point! You can also host the JS script yourself, or use the on-premises version (Docker image)

hknd 8y ago

Didn't think that I'll find an application in 2018 which will use ExtJS, but therootcause dashboard is using it (:

mankz 8y ago
Curious - why does it matter to you if the UI is built using Ext, Vue or React?
- hknd 8y ago
  [disclaimer: I'm a java/js/... dev at a faang company, and I've used Ext before] Imho Ext is a specialty of all the existing UI frameworks, and imho it's shit. Tbh I though it would die directly after being bought by Idera. Even most of the most Senior people left or got fired after that. Most annoying things (imho): - lock in: all their widgets, and tooling, and everything only works for Sencha products, and is by far worse than the current open source counterparts - price: for a SMB/big-company this doesn't matter, but you pay a premium to use "widgets" which are worse (imho) than open source - Sencha Widgets compile into clunky and non-semantic HTML (thousands of divs), which also impacts performance a lot: simple apps usually have 3-5MB - debugging is difficult as you have to go through their "OOP" layers (can be 5-10 layers) [Java Developers created this Web Framework] People argue that it's great because many rich widgets are already available and because the framework tells you how do to stuff. But everyone will run into a point in time where something is just extremely hard because of extjs constraints, which usually ends in a hacky solution.
  - mankz 8y ago
    Sounds you had a very bad experience with Ext JS, but we hope you'll give RootCause a go anyway :)
    - hknd 8y ago
      Well, I'll definitely try it out. I don't make up my mind just because I don't like a technology personally.

bsimpson 8y ago

You'd want to be really careful recording/replaying sessions on pages that capture personally identifiable information; then again, you probably wouldn't be running a third-party service like this if you were.

koolba 8y ago
> ... then again, you probably wouldn't be running a third-party service like this if you were. While we'd like that to be true it's sadly not in practice. The most common example is websites with sensitive data in the URL (ex: PII query parameters) using third party analytics services that receive the entire URL as a metric.
mankz 8y ago
The RootCause API has multiple ways to scrub PII details from the session before posting it. And we also offer an on-premises version (Docker image) so that the data never leaves your own servers.

deleted 8y ago

[deleted]

nickreese 8y ago

Wow, this is impressively polished. Will look for an opportunity to test it out on a project we're working on.

k1ns 8y ago

This is great. Well done. The demo had me laughing in a very good way (I was genuinely having fun watching it replay).

hashkb 8y ago

Hugged to death. Wonder what they use for backend errors.

RussianCow 8y ago

Looks neat and particularly polished for a Show HN. I especially loved the sandbox demo. However, I don't see anything that this offers that LogRocket[0] doesn't already have. How does RootCause compare? [0]: https://logrocket.com/ https://logrocket.com/

mankz 8y ago
LogRocket is very neat looking but only does replay for Redux apps (as far as I know). We record all events for any web app so you can replay session and fire the exact same mouse+keyboard+ajax events to reproduce the issue. Very similar tools but we wanted to make something generic targeting every web app
- RussianCow 8y ago
  I believe that's how they started, but that's no longer true of LogRocket—their service does not depend on Redux, though they offer a very nice integration with it if you happen to use it.
jchook 8y ago
I agree. Very polished. We use FullStory and it’s fantastic. Would be extremely difficult to convert me. https://www.fullstory.com/ https://www.fullstory.com/
- saganus 8y ago
  Both LogRocket and FullStory are blocked by default by uMatrix. Any idea why?
  - willriker 8y ago
    I believe they are both classified as analytics tools which is why they are blocked. It's annoying that uMatrix will still block a tool even if you purposefully navigate to their site (versus if the tool is used for analytics on a different company's site).

igotsideas 8y ago

The site is down for me.

mankz 8y ago
Issue with GoDaddy load balancing :( We're on the phone with them now
- mankz 8y ago
  Site back up :)

audiolion 8y ago

Looks like a direct competitor to https://sessionstack.io https://sessionstack.io I am not sure how I feel about these session recorders and probably want to start blocking them from my browser. It is akin to someone recording your every movement inside your house and watching the video to see what issues come up. Oh and you have no idea its happening. Also wonder about how this data is protected. If videos of how I used Facebook were leaked (messages I started to type but didnt send for instance) it would be a huge violation of my privacy. In the same token, its like free UX research, you can see where people struggle by watching them use the app. It is like standing over someone's shoulder to see how they are using the product and helps immensely in that realm. I still feel like it should be opt in though.

mankz 8y ago
Very valid points, great feedback and we completely agree, here's how we address this: 1. We recommend all our users to use the opt-in prompt before an error is logged. Demo: https://app.therootcause.io/sandbox/confirmation/ https://app.therootcause.io/sandbox/confirmation/ 2. We can also show a special icon in bottom right corner when video is recorded. Demo: https://app.therootcause.io/sandbox/videorecording/ https://app.therootcause.io/sandbox/videorecording/ And, it's not just about production sites - another use case is using this internally as a tool between QA <-> Developers to speed up communication when new errors are found.

kerkeslager 8y ago

The fact that tools like this are needed should be understood to mean that JavaScript error handling is fundamentally broken. In a reasonable language, you do something obviously wrong, and it throws an exception immediately, which gives you a stack trace that gives reasonable context for understanding what went wrong. In JavaScript, the failure often happens silently: "foo" + 1 returns "foo1", {}.foo returns undefined, and program execution continues until it absolutely can't, finally failing far away from where the problem occurred. And when it does fail, it often fails in a callback deep within framework code with no clear, traceable execution path that leads back to the point where the error occurred. The errors have all the mysteriousness of C errors, without even the traceability. The JavaScript community doesn't seem to be aware that there are better solutions, and seem happy with the way things are, even going so far as to use JavaScript on servers where far better tools exist. It seems that the only salvation that will come will be when mature tools exist on top of WebAssembly so that those of us who care about error reporting can use better toolchains.

brlewis 8y ago
You need a tool like this to monitor run-time browser errors. When browsers support a language that catches 100% of errors at compile time then you won't need tools like this. But I see what you're saying. Except for the declarative style popularized by React and also implemented in Mithril, Preact and Inferno, and except for the rise in popularity of TypeScript, and except for a lot of attention paid lately to immutable data structures, and except for jslint being created in 2002 and lots of similar tools since then, and except for the wide variety of JavaScript-based unit test frameworks, it really seems like the JavaScript community has no clue that there are ways to prevent the errors you describe and no inclination to prevent them.
- kerkeslager 8y ago
  > You need a tool like this to monitor run-time browser errors. When browsers support a language that catches 100% of errors at compile time then you won't need tools like this. Eh, I don't think that logging runtime-in-the browser is the value added here. I can wrap my codebase in a try-catch that catches exceptions and calls home with the stack trace in < 100 lines of code. Avoiding that < 100 lines of code isn't the value added.

spraak 8y ago

I wonder why they didn't register https://www.rootcause.io/ https://www.rootcause.io/ (i.e. why the "the" in the url)

mankz 8y ago
Taken already

fiatjaf 8y ago

Unless you running a million-user app, I believe you shouldn't fall for this. I have, multiple times. I've tried to catch what users were doing and get a log of the exceptions they faced. Only despair followed from these attempts. The best error handling technique is to catch exceptions and show up a big popup on the screen with the error details. Your users will send those details to you instead of just saying "the app crashed".

mankz 8y ago
You sum it up well. If you just get static text (call stack etc) from your error logger tool, it's of almost no use as it doesn't reveal the state of the app. With modern tools that have replay capability, this changes and the debugging process is so much nicer. :)
- Can_Not 8y ago
  Every error tracker I've ever used allows you to send arbitrary data (which could be your entire flux store, for example) and has great documentation on how to start using it.
  - mankz 8y ago
    We also allow you to attach any custom data to the error report. But this doesn't necessarily help you put the web application into the state where it crashes. Demo of custom data: https://app.therootcause.io/sandbox/addingcustomdata/ https://app.therootcause.io/sandbox/addingcustomdata/
Can_Not 8y ago
In my experience, users can't be bothered to copy and paste those errors. One feature of <literally any error tracker> is to give the user a code instead of the raw stack. This pairs well with the feature to attach arbitrary data (like current state, or atleast just user id), then you can see the whole error data in the tool on your own computer. I've been able to fix bugs before the support staff approaches me about it.

vbsteven 8y ago

I find it funny that here on HN in one thread we complain about Facebook scanning all of our messages while in the next thread we praise a product that tracks JavaScript events, keystrokes and mouse movements...

chacham15 8y ago

Random question: I've had bugs which were a simple result of timing (mostly due to the cpu being used by other processes running on the users machine), how would something like this be able to replay that error for me? If I were to replay that same data on my machine, because of the availability of cpu horsepower on my machine, I wouldnt be able to reproduce the error. Does anyone have insight to this?

mankz 8y ago
Race condition bugs are very tricky to reproduce indeed. While there will never be a guarantee our Live Replay will reproduce your issue - it should be possible since we replay all events in the exact sequence they were recorded. Our replay studio also has a 'Preserve timing' setting which uses the same delay between the events.

Annika11 8y ago

Nice!