Ask HN: How do you get a grip on phantom errors?
Most of us already had it: you thought all errors in your app have finally been ironed out and then someone sends you an ugly screenshot showing an even more ugly error you cannot reproduce. He's not tech savvy enough to tell you details about his system config and cannot reliably reproduce the error himself. But the screenshot shows: it's out there. How do you get a grip on that?
3 comments
I've had this happen many times on random users' systems. If the user is nice enough to work with you (and they were in my case since they were caught pre-deployment in contract work), you can often ask them to try new things with a dev build for instance.
The main key is to reproduce the errors on your system, so just try a bunch of wacky things like different screen resolutions, memory constraints, database configurations, etc. Continually look at the code and brainstorm what might cause that issue -- there are a limited number of code paths -- and try to cause the constraints in your code. It's definitely very specific to the individual situation.
The main key is to reproduce the errors on your system, so just try a bunch of wacky things like different screen resolutions, memory constraints, database configurations, etc. Continually look at the code and brainstorm what might cause that issue -- there are a limited number of code paths -- and try to cause the constraints in your code. It's definitely very specific to the individual situation.
Without the screenshot and an idea of the applications state at that moment that's kind of hard to answer.
What you could do, is figure out the IP address of the user (that shouldn't be too hard), then go back into the log files and check all their actions one by one rebuilding the state up to the moment of the bugs occurrence.
Chances are that you'll be able to reproduce it that way, even if the user is clueless.
This little trick saved my ass a couple of times.
What you could do, is figure out the IP address of the user (that shouldn't be too hard), then go back into the log files and check all their actions one by one rebuilding the state up to the moment of the bugs occurrence.
Chances are that you'll be able to reproduce it that way, even if the user is clueless.
This little trick saved my ass a couple of times.
Mark it as 'unable to reproduce' and don't worry too much about it until you get enough information to track down the cause. It sort of sucks, but if very few users are seeing the problem, sometimes it's not worth the effort unless you get a clear lead as to the cause of the problem.