3 ms·

For debugging purposes, because having users tell you what error they got is sometimes very useful: generate a random number (e.g. a uuid), log it with the err

by Groxx 1y ago

For debugging purposes, because having users tell you what error they got is sometimes very useful: generate a random number (e.g. a uuid), log it with the error, and display that number. doesn't leak data because it's different every time, but you can uniquely pair it up with what they are seeing.

ChrisMarshallNY 1y ago
That's a good idea!
spockz 1y ago
Better yet. Just use the trace id for the message. That id is correlated with all log statements already and it will allow you to in one go follow the whole flow of the user without setting up another per-request flow lookup table.
- RadiozRadioz 1y ago
  The prerequisite to this is setting up OTEL tracing and having already instrumented everything. Which is not trivial. You can't "just use" it. It's like you get to the middle of a recipe and they say to "just" add in the meat you've already been marinating for 48 hours.
  - Groxx 1y ago
    you really only need it at the entry point to have a trace ID... but yeah. tracing is hard to add on later, though I'm glad it's becoming more common for newer code.
  - spockz 1y ago
    Telemetry for me is table stakes. We have been doing forms of tracing (first home grown) since 2012. Strictly speaking only the edge gateway needs to know about it. Tracing is trivial to add with OTel. It is trivial with Spring Boot (since v3). At least on technical endpoint level. Adding tracing to business logic obviously requires work, but simple propagation is table stakes.
kmoser 1y ago
I like to have the error message include the line number that emitted it, e.g. "Unable to log in to your account (error code 123)". This comes in handy especially when you don't want (or are unable) to log messages, and/or several lines emit the same error message. So line 123 might be because no DB connection could be established, while line 456 might be because the connection timed out.
- ChrisMarshallNY 1y ago
  I have found that having this in the user-facing message is not helpful. It seems that the parent suggestion is unpopular, but having a technically-available log, with a reference from an entry, seems to be a good compromise. Bit more work for the developer, but less for the user, which is really the goal.
- deleted 1y ago
  [deleted]

by Groxx 1y ago

ChrisMarshallNY 1y ago

That's a good idea!

spockz 1y ago

Better yet. Just use the trace id for the message. That id is correlated with all log statements already and it will allow you to in one go follow the whole flow of the user without setting up another per-request flow lookup table.

RadiozRadioz 1y ago
The prerequisite to this is setting up OTEL tracing and having already instrumented everything. Which is not trivial. You can't "just use" it. It's like you get to the middle of a recipe and they say to "just" add in the meat you've already been marinating for 48 hours.
- Groxx 1y ago
  you really only need it at the entry point to have a trace ID... but yeah. tracing is hard to add on later, though I'm glad it's becoming more common for newer code.
- spockz 1y ago
  Telemetry for me is table stakes. We have been doing forms of tracing (first home grown) since 2012. Strictly speaking only the edge gateway needs to know about it. Tracing is trivial to add with OTel. It is trivial with Spring Boot (since v3). At least on technical endpoint level. Adding tracing to business logic obviously requires work, but simple propagation is table stakes.

kmoser 1y ago

I like to have the error message include the line number that emitted it, e.g. "Unable to log in to your account (error code 123)". This comes in handy especially when you don't want (or are unable) to log messages, and/or several lines emit the same error message. So line 123 might be because no DB connection could be established, while line 456 might be because the connection timed out.

ChrisMarshallNY 1y ago
I have found that having this in the user-facing message is not helpful. It seems that the parent suggestion is unpopular, but having a technically-available log, with a reference from an entry, seems to be a good compromise. Bit more work for the developer, but less for the user, which is really the goal.
deleted 1y ago
[deleted]