> 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.
* 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