What is a "handler span"?

[trask]

Related to #3140.

Here's one proposal:

---

Most web frameworks have a concept of routing and handlers.

Handler spans have a couple of purposes:

• They represent the portion of a request that is spent in an application handler (as opposed to time spent in the web framework)
• They help users map requests easily to application code (while server span names are based on url paths, the handler span names are based on application class name / method name)

Note: If user code returns a "promise" of some kind (e.g. Future, Mono) the handler span should end when the promise completes.

---

I think this is mostly consistent with how we implement handler spans, with a couple of questions so far:

• If a route is not found (and no application handler is invoked), should we capture a handler span? (currently in some cases we do and in some cases we don't)

• The current webflux handler span maps to ServerWebExchange.handle(), which is pretty much the entire request-response lifecycle (including routing), it would be nice if this can be scoped down a bit

[anuraaga]

Another question is whether we should have these without adding something to the spec.

[iNikem]

I don't think we are ready and should introduce one more concept to our instrumentations. I mean, we (as Otel community as a whole) have not yet solved the problem with (nested) CLIENT spans. Should we open one more can of worms before we close that one?

[trask]

Closing, these spans are now opt-in under an experimental flag, can revisit later if anyone has renewed interest.