3 ms·

If your codebase has the concept of a request ID, you could also feasibly use that to trace what a user has been doing with more specificity.

by spike021 10mo ago

mnahkies 10mo ago
We do have both a span id and trace id - but I personally find this more cumbersome over filtering on a user id. YMMV if you're interested in a single trace then you'd filter for that, but I find you often also care what happened "around" a trace
ivan_gammel 10mo ago
…and the same ID can be displayed to user on HTTP 500 with the support contact, making life of everyone much easier.
- dexwiz 10mo ago
  I have seen pushback on this kind of behavior because "users don't like error codes" or other such nonsense. UX and Product like to pretend nothing will ever break, and when it does they want some funny little image, not useful output. A good compromise is to log whenever a user would see the error code, and treat those events with very high priority.
  - ivan_gammel 10mo ago
    Nah, that’s easy problem to solve with UX copy. „Something went wrong. Try again or contact support. Your support request number is XXXX XXXX“ (base 58 version of UUID).
  - spockz 10mo ago
    We put the error code behind a kind of message/dialog that invites the user to contact us if the problem persists and then report that code. It’s my long standing wish to be able to link traces/errors automatically to callers when they call the helpdesk. We have all the required information. It’s just that the helpdesk has actually very little use for this level of detail. So they can only attach it to the ticket so that actual application teams don’t have to search for it.
  - inkyoto 10mo ago
    > I have seen pushback on this kind of behavior because "users don't like error codes" or other such nonsense […] There are two dimensions to it: UX and security. Displaying excessive technical information on an end-user interface will complicate support and likely reveal too much about the internal system design, making it vulnerable to external attacks. The latter is particularly concerning for any design facing the public internet. A frequently recommended approach is exception shielding. It involves logging two messages upon encountering a problem: a nondescript user-facing message (potentially including a reference ID pinpointing the problem in space and time) and a detailed internal message with the problem’s details and context for L3 support / engineering.
    - dist1ll 10mo ago
      Sorry for the OT response, I was curious about this comment[0] you made a while back. How did you measure memory transfer speed? [0] https://news.ycombinator.com/item?id=38820893 https://news.ycombinator.com/item?id=38820893
      - inkyoto 10mo ago
        I used «powermetrics» bundled with macOS with «bandwidth» as one of the samplers (--samplers / -s set to «cpu_power,gpu_power,thermal,bandwidth»). Unfortunately, Apple has taken out the «bandwidth» sampler from «powermetrics», and it is no longer possible to measure the memory bandwidth as easily.
  - KronisLV 10mo ago
    > UX and Product like to pretend nothing will ever break, and when it does they want some funny little image, not useful output. Just ignore them or provide appeasement insofar that it doesn’t mess with your ability to maintain the system. (cat picture or something) Oh no, something went wrong. Please don’t hesitate to reach out to our support: (details) This code will better help us understand what happened: (request or trace ID)
nine_k 10mo ago
...if it does not, you should add it. A request ID, trace ID, correlation key, whatever you call it, you should thread it through every remote call, if you value your sanity.
kulahan 10mo ago
If you care about this more than anything else (e.g. if you care about audits a LOT and need them perfect), you can simply code the app via action paths, rather than for modularity. It makes changes harder down the road, but for codebases that don’t change much, this can be a viable tradeoff to significantly improve tracing and logging.

If your codebase has the concept of a request ID, you could also feasibly use that to trace what a user has been doing with more specificity.

mnahkies 10mo ago

We do have both a span id and trace id - but I personally find this more cumbersome over filtering on a user id. YMMV if you're interested in a single trace then you'd filter for that, but I find you often also care what happened "around" a trace

ivan_gammel 10mo ago

…and the same ID can be displayed to user on HTTP 500 with the support contact, making life of everyone much easier.

dexwiz 10mo ago
I have seen pushback on this kind of behavior because "users don't like error codes" or other such nonsense. UX and Product like to pretend nothing will ever break, and when it does they want some funny little image, not useful output. A good compromise is to log whenever a user would see the error code, and treat those events with very high priority.
- ivan_gammel 10mo ago
  Nah, that’s easy problem to solve with UX copy. „Something went wrong. Try again or contact support. Your support request number is XXXX XXXX“ (base 58 version of UUID).
- spockz 10mo ago
  We put the error code behind a kind of message/dialog that invites the user to contact us if the problem persists and then report that code. It’s my long standing wish to be able to link traces/errors automatically to callers when they call the helpdesk. We have all the required information. It’s just that the helpdesk has actually very little use for this level of detail. So they can only attach it to the ticket so that actual application teams don’t have to search for it.
- inkyoto 10mo ago
  > I have seen pushback on this kind of behavior because "users don't like error codes" or other such nonsense […] There are two dimensions to it: UX and security. Displaying excessive technical information on an end-user interface will complicate support and likely reveal too much about the internal system design, making it vulnerable to external attacks. The latter is particularly concerning for any design facing the public internet. A frequently recommended approach is exception shielding. It involves logging two messages upon encountering a problem: a nondescript user-facing message (potentially including a reference ID pinpointing the problem in space and time) and a detailed internal message with the problem’s details and context for L3 support / engineering.
  - dist1ll 10mo ago
    Sorry for the OT response, I was curious about this comment[0] you made a while back. How did you measure memory transfer speed? [0] https://news.ycombinator.com/item?id=38820893 https://news.ycombinator.com/item?id=38820893
    - inkyoto 10mo ago
      I used «powermetrics» bundled with macOS with «bandwidth» as one of the samplers (--samplers / -s set to «cpu_power,gpu_power,thermal,bandwidth»). Unfortunately, Apple has taken out the «bandwidth» sampler from «powermetrics», and it is no longer possible to measure the memory bandwidth as easily.
- KronisLV 10mo ago
  > UX and Product like to pretend nothing will ever break, and when it does they want some funny little image, not useful output. Just ignore them or provide appeasement insofar that it doesn’t mess with your ability to maintain the system. (cat picture or something) Oh no, something went wrong. Please don’t hesitate to reach out to our support: (details) This code will better help us understand what happened: (request or trace ID)

nine_k 10mo ago

...if it does not, you should add it. A request ID, trace ID, correlation key, whatever you call it, you should thread it through every remote call, if you value your sanity.

kulahan 10mo ago

If you care about this more than anything else (e.g. if you care about audits a LOT and need them perfect), you can simply code the app via action paths, rather than for modularity. It makes changes harder down the road, but for codebases that don’t change much, this can be a viable tradeoff to significantly improve tracing and logging.