If you don't work on lakeFS code, you can safely s...
# dev
If you don't work on lakeFS code, you can safely stop reading. tl;dr: 1. Except for startup and shutdown actions, your loggers should always have context fields from them. a. Use
to incorporate context fields into an existing Logger . b. Use`logging.FromContext` to create a new Logger with context fields. c. I've renamed
to the slightly harder to type and less pleasant to read
. tl: We use context fields, specifically the request ID, to connect the different logs emitted while processing a single request. Without these it can be very difficult to understand the flow of a single request. All you have to do is use
to create your Logger or
to mix existing context with an existing Logger. The only reason not to use context on your Logger is in tests, during startup, or during shutdown. Even in these cases, you often have a context simply to be able to perform other operations. The context for a
req http.Request
, and middleware at the start of the chain puts the request ID onto it. In almost every func that performs an operation there will be a
ctx context.Context
that holds a context. Use it! Over time we drifted away from this, and many of our logs lost their request IDs. I've just pulled treeverse/lakeFS#6312. It fixes all the uses that I could find that were missing a context. I also took the liberty of renaming
. This should encourage you to use a context - 2 fewer characters to type and a happier
! Please call out its uses when reviewing code. Thanks for adding context to all our debugging sessions!
👍🏽 2