Not a bot, I promise, saw this on twitter! It looked interesting at first glance, but now that I've had a chance to read it, this is a great overview of different approaches to using request contexts and the pitfalls of each.

You shouldn't store a logger there if it isn't created specifically to be scoped to this request, and likewise you shouldn't store a generic database connection in a context value.

I'd go further than this and say you should never store a logger or a db connection on a request - why would you want a request scoped logger, simply to log the request id? I don't see anything wrong with attaching a trace to the context in middleware which is then used by inner functions - if you are using a middleware chain and use it only for functions which are applied universally to all handlers. I really like the idea of typed Getters and Setters for context though, this makes it a lot cleaner, and also lets you put those in the same package which mutates the context (say your logging package for example).