In service discovery, why does ServiceEndpointWatcher suppress ExecutionContext flow to the refresh task?

[jlledo]

I've implemented an IServiceEndpointProvider that makes HTTP requests and was suprised to see they've got a different trace ID from my subsequent requests to the actual resolved service endpoint.

This behaviour is unexpected so I went digging and, after much learning and debugging, found that ServiceEndpointWatcher suppresses ExecutionContext flow to the endpoint refresh task. Which I assume is the reason why Activity.Current is not set when my discovery task resumes in another thread.

I'm sure there's a good reason, given the code has a comment explicitly calling it out:

// Don't capture the current ExecutionContext and its AsyncLocals onto the callback.

but I haven't found any clues in git history, so what gives?

I'm just looking to satisfy my curiosity, thanks in advance.

[ReubenBond]

The main reason is that there is a timer scheduled from within it and we wouldn't want to restore that captured context within that (it would be rude and could lead to unexpected behavior). More generally, I considered the refresh to be a background process, not tied to any particular request. We could push the context suppression to just around timer scheduling if that would improve some experience

[jlledo]

That makes sense, thanks.

I think suppression should be kept in place because I agree that refreshing is a background task - it just happens to be temporally coupled to outgoing requests to prevent failures when the cache isn't yet populated.