Discussion: Silent logging or better request/response lifecycle hooks?

[endgame]

trafficstars

I was writing some code the other day that talks to DynamoDB, where it's sometimes necessary to make conditional requests that are expected to fail. At higher logging levels, these generate noisy and irrelevant log messages (see also: #584), but we can't turn off logging for that one request without potentially missing failures for other reasons.

I went to add some more hooks to Env to selectively silence certain log messages, but then I started to wonder: what if we replaced the logging stuff with a bunch of hooks that are called before/after different points in the request/response cycle? Then logging becomes a single special case, albeit one where we can provide sensible defaults.

Thoughts @brendanhay ?

CC: @fuuzetsu, @lrworth @unisay who may also be affected.

[Fuuzetsu]

Then logging becomes a single special case, albeit one where we can provide sensible defaults.

Unless there is a vast array of other cases (maybe tracing stuff? unsure) this sounds more difficult to get right/usable than necessary. I think it's probably fairly easy to do something that works for logging though.

FWIW I haven't really been adding any new amazonka code so I don't have much of a stake.

[lrworth]

vast array of other cases

It could be useful for adding X-Ray tracing to AWS calls.

[endgame]

Another use case for request/response hooks: rewriting requests for non-S3 object stores. See #760.