Open arv opened 2 years ago
Yes this seems sensible, when it comes time to implement I'd like to talk about what goes into the message vs the attached extra context. There are a couple of ways we could go and it has bearing on how we log server-side, because we use LogContext ubiquitously and have have a few requirements on the server that are less relevant on the client.
I was looking at this and a few questions (trying to setup Sentry myself to experiment):
@aboodman Sentry can be configured how to group issues. But it is a more sophisticated effort and I think having sane grouping by default would be beneficial.
The way I solved this now, is by wrapping error level logs into errors and parsing the log info into an object in order to attach it to the error: https://gist.github.com/KeKs0r/ece9a454561bb864f806549d3b8e715c
We have an internal class called
LogContext
. It's implementation is at https://github.com/rocicorp/logger/blob/main/src/logger.ts#L145Basic usage is:
This might not be too bad if it wasn't that our context always starts with the clientID which is ephemeral. For tools like Sentry that means that it is impossible to group the log lines.
An alternative approach would be to attach the context as a "JSON object". Then we would get something like:
Then sentry would display this something along the lines of: