[Code Origin] Treat Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore as 3rd party#8628
Conversation
…third-party Add Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore to the ThirdPartyModules name list so AssemblyFilter.ShouldSkipAssembly returns true for it. Without this, Code Origin attributes Azure Functions Isolated HTTP entry spans to FunctionsHttpContextExtensions.InvokeFunctionAsync instead of skipping the framework assembly. Co-authored-by: Cursor <[email protected]>
BenchmarksBenchmark execution time: 2026-05-13 14:27:36 Comparing candidate commit 7157e47 in PR branch Some scenarios are present only in baseline or only in candidate runs. If you didn't create or remove some scenarios in your branch, this maybe a sign of crashed benchmarks 💥💥💥 Scenarios present only in baseline:
Found 1 performance improvements and 2 performance regressions! Performance is the same for 48 metrics, 21 unstable metrics, 87 known flaky benchmarks, 39 flaky benchmarks without significant changes.
|
Summary of changes
Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCoreto the embeddedThirdPartyModulesname list.Reason for change
AssemblyFilter.ShouldSkipAssembly(used bySpanCodeOrigin.SetCodeOriginForEntrySpan) consultsThirdPartyModules.Containsfor case-sensitive exact-match membership against the assembly's simple name.Microsoft.AspNetCore.Http.FunctionsHttpContextExtensions, which is what ASP.NET Core endpoint resolution surfaces for Azure Functions Isolated HTTP triggers. Because the assembly was missing from the list, Code Origin attributes the entry frame toFunctionsHttpContextExtensions.InvokeFunctionAsync- a framework method - instead of skipping the assembly entirely.Implementation details
Microsoft.Azure.Functions.Worker.*family.