> We can't reproduce that

But that doesn't mean it isn't happening. It doesn't even mean that *most* people aren't getting the error — it just means that we aren't. And we have no real idea who is, and how much pain it is causing.

Well from now on we feel your pain. Sort of. TopAnswers will call back to the server if it catches a JavaScript error in our code running in your browser, and we will log the details[^1] anonymously. We considered making this an opt-in feature and  logging the errors with a link to the logged-in account, but it's probably

* unnecessary to link to the account anyway, and
* better to have a wide view of the problem[^2]

We are logging the following for each error:

1. a timestamp
1. the JS error text
1. the [user agent](https://en.wikipedia.org/wiki/User_agent) that your browser sends to our server

If you are wondering whether this will really be useful here is an example: [this commit](https://github.com/topanswers/topanswers/commit/612f87af7f4574576c9f70cdac01235a2a9feb64) was made at 16:57 on Friday, after seeing [this JS error](https://topanswers.xyz/transcript?room=1&id=61216#c61216) at 16:03. Before that we'd had reports of an intermittent rendering problem, which we couldn't reproduce, going back [at least 11 days](https://github.com/topanswers/topanswers/issues/87). It was probably really occuring ever since mid-May when we [implemented resource versioning](https://topanswers.xyz/meta?q=1015). Just having sight of the JS error[^3] made the fix a piece of cake.

Obviously it won't magically make all bug fixes easy, but we think it will make a big difference to some of those that are most frustrating for you.

[^1]: in an [unlogged table](https://www.depesz.com/2011/01/03/waiting-for-9-1-unlogged-tables/) — this isn't data we need to keep long-term
[^2]: not too wide though — we are only logging errors for authenticated sessions
[^3]: which can be hard to capture if it only occurs on mobile