Closed davidfowl closed 5 years ago
Sounds like there will be a race condition for something at the start no matter what we do. I may be able to iterate through the list of startup filters and insert at the point just before I find one that is called AutoRequestServicesStartupFilter
... but that's also a potential issue if names change or the pipeline changes how request services get populated.
We can probably update the logic to search for AutoRequestServicesStartupFilter
and if it finds it, great, insert just before; if not, insert at zero.
I wonder if there are other race conditions like that or different/better ways to extend things like the request services setup. Hmmmm.
In any case, I can look at an enhancement to adjust as needed. Thanks for the heads up.
The one potential breaking change is for things like Autofac.Multitenant (https://github.com/autofac/Autofac.AspNetCore.Multitenant/blob/6ab27ab5312159da2f50e4d8f88dfbca670fb09e/src/Autofac.Integration.AspNetCore.Multitenant/AutofacMultitenantWebHostBuilderExtensions.cs#L65). They inject themselves as the first Startup filter which means request diagnostics would run after instead of before.
cc @tillig
There are probably other subtle changes to when things run but I'm hoping those specific details don't matter too much. This enables extensibility through existing mechanisms (like middleware) instead of adding more specific hooks to hosting.