It's not very clear what handler means, and we don't see the start and end of the request processing, which could be useful especially once we introduce extra debug logs or just to see request duration. Also, this should probably be an info log. So something like this:
Let's also make sure that any errors are logged correctly and only once. Refer to #177562455 for details about how we want to log errors.
Dev Notes
Ensure logs are correlated using lager session IDs. This requires using the logger.Session method and passing the logger through method calls. It will not work if the logger is stored in a struct.
Logger can be passed as an explicit method argument, or might also be passed as part of the context object that is already passed around (see the https://github.com/cloudfoundry/lager/tree/master/lagerctx package, and note in this story). With lagerctx, there is the risk of accidentally and unknowingly using the fallback discard logger if the original context is somehow lost while passing through methods. So explicitly passing both context and logger as separate method parameters throughout might be the safest option, giving compile-time guarantees of having logging correctly propagated.
This is how logs look like when stopping an LRP instance:
It's not very clear what
handlermeans, and we don't see the start and end of the request processing, which could be useful especially once we introduce extra debug logs or just to see request duration. Also, this should probably be aninfolog. So something like this:Let's also make sure that any errors are logged correctly and only once. Refer to #177562455 for details about how we want to log errors.
Dev Notes
Ensure logs are correlated using lager session IDs. This requires using the
logger.Sessionmethod and passing the logger through method calls. It will not work if the logger is stored in a struct.Logger can be passed as an explicit method argument, or might also be passed as part of the context object that is already passed around (see the https://github.com/cloudfoundry/lager/tree/master/lagerctx package, and note in this story). With lagerctx, there is the risk of accidentally and unknowingly using the fallback discard logger if the original context is somehow lost while passing through methods. So explicitly passing both context and logger as separate method parameters throughout might be the safest option, giving compile-time guarantees of having logging correctly propagated.