I've needed this a few times

Yes, if an outer interceptor or routing map could stick something into the context that meant "please log the interceptor transitions for this request" [which could even be retroactive to any prior interceptors that had already handled it], that would be super! As to the level of detail - I would be happy with the minimum, i.e., name of interceptor and whether it made any changes at all. Once the systemic logging has brought me up to speed on which interceptors are relevant, then I can expressly log further details myself. In other words, it would be a matter of diminishing returns for Pedestal to try to figure out the helpful level of detail.

I’ve also been thinking about a event based system, where events would be broadcast (i..e, a function would be invoked) after each interceptor’s execution, passing before-and-after context map (possibly, with some internal-use-only keys dissoc’ed). What I described above could be built on top of that, though not necessarily phill’s suggestion (as it is retroactive and stateful).

A function: tap> Maybe this can be part of "interceptor compiling" step.

I’ve felt that tap> should be reserved for the application to do as it sees fit; the moment we have libraries/frameworks using tap> is the moment we start having issues with conflicting things being tap-ed.

Will there be otel trace spans for these events? That seems like it could be useful and would remove a lot of the manual span creation in my apps.

I don’t have a detailed design. That being said, the challenge is knowing when to stop a started span. Also, spans that last microseconds aren’t useful; just those that do I/o and can block for an appreciable amount of time.

So span for each interceptor is not useful and will generate a lot of noise.

Good point