You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Logging.EventSource tests failing on iOS with NullReferenceException in OnEventWritten #127449
Microsoft.Extensions.Logging.EventSource.Tests failing on iOS and likely all mobile platforms with NullReferenceExceptions in EventSource.OnEventWritten.
Failure Pattern
All 8 failing tests report:
ERROR: Exception during EventSource.OnEventWritten: Object reference not set to an instance of an object.
Assert.Collection() Failure: Item comparison failure
Error: Event name does not match. Expected Message, event data is '{"__EVENT_NAME":"EventSourceMessage","message":"ERROR: Exception during EventSource.OnEventWritten: Object reference not set to an instance of an object."}'
Failing Tests
Logs_OnlyMessage_IfKeywordSet
Logs_TracingDetailsAsExpected_WithDefaults (4 theory variants)
Logs_OnlyFormattedMessage_IfKeywordSet
Logs_AsExpected_WithDefaults
Logs_AsExpected_WithDefaults_EnabledEarly
Platform Coverage
Confirmed on:
iossimulator-arm64 CoreCLR
Likely affects all mobile platforms (tvOS, MacCatalyst, Android) based on failure pattern.
Helix Job:7da59944-242f-4296-8a21-1a36fe1d0562 Work Item:Microsoft.Extensions.Logging.EventSource.Tests
Console log shows the EventSource implementation itself is throwing a NullReferenceException during event writing, not the test code.
Related
Likely related to recent changes around trimming, reflection, or EventSource handling on mobile/NativeAOT platforms. See also #127448 for concurrent DI/Hosting failures on the same build.
Note
🔒 Integrity filter blocked 3 items
The following items were blocked because they don't meet the GitHub integrity level.
#126023search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
#124461search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
#108513search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
To allow these resources, lower min-integrity in your GitHub frontmatter:
<ItemGroupCondition="('$(TargetOS)' != 'browser' and '$(RunAOTCompilation)' == 'true' and '$(MonoForceInterpreter)' != 'true') or ('$(TargetOS)' == 'browser' and '$(BuildAOTTestsOnHelix)' == 'true' and '$(RunDisabledWasmTests)' != 'true') or (('$(TargetOS)' == 'ios' or '$(TargetOS)' == 'tvos' or '$(TargetOS)' == 'maccatalyst') and '$(BuildTestsOnHelix)' == 'true')">
is not correctly excluding the iossimulator and tvossimulator.
@vitek-karas@MichalStrehovsky do you think the trimming is aggressive? should preserve EventSource event metadata. The [DynamicDependency] and [UnconditionalSuppressMessage] attributes on LoggingEventSource may not be sufficient under aggressive trimming?
@vitek-karas@MichalStrehovsky do you think the trimming is aggressive? should preserve EventSource event metadata. The [DynamicDependency] and [UnconditionalSuppressMessage] attributes on LoggingEventSource may not be sufficient under aggressive trimming?
The core invariant we have for trimming is that if no trimming warnings are generated, the code needs to work. The test itself doesn't seem to be triggering trimming warnings. The trimming analyzer on the test itself is enabled (default value is now enabled and I don't see <EnableTrimAnalyzer>false</EnableTrimAnalyzer> in this test project; there is a <EnableAotAnalyzer>false</EnableAotAnalyzer> in the test project but that's irrelevant for non-native AOT testing). So if there was a trimming issue in the test code itself, the analyzer would warn and break the build.
So if the test is hitting issues after trimming, it's a product bug. We likely put [UnconditionalSuppressMessage] on something in the product that is not actually safe with trimming. We either need to make it safe, or do a breaking change and declare this library as not compatible with trimming so that users get a proper build time warning when using it.
What a coincidence - looks like the test is using Newtonsoft JSON (😕) and we just picked up an upgrade to Newtonsoft JSON that marks all the APIs as trimming incompatible. This is now triggering a warning in this test:
It is not clear to me if this is related (I don't know about EventSource or logging), but could be. Would be nice not to use Newtonsoft as a general hygiene. Then we'd also know better if this is a product bug or not.
Activity
dotnet-policy-service commentedon Apr 27, 2026
Tagging subscribers to 'os-ios': @vitek-karas, @kotlarmilos, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.
dotnet-policy-service commentedon Apr 27, 2026
Tagging subscribers to 'os-maccatalyst': @vitek-karas, @kotlarmilos, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.
dotnet-policy-service commentedon Apr 27, 2026
Tagging subscribers to this area: @dotnet/area-extensions-logging
See info in area-owners.md if you want to be subscribed.
dotnet-policy-service commentedon Apr 27, 2026
Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.
dotnet-policy-service commentedon Apr 27, 2026
Tagging subscribers to 'os-tvos': @vitek-karas, @kotlarmilos, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.
tarekgh commentedon Apr 27, 2026
Looks the condition in
runtime/src/libraries/tests.proj
Line 381 in 14d3e32
iossimulatorandtvossimulator.#127448 maybe similar root cause.
tarekgh commentedon Apr 27, 2026
@vitek-karas @MichalStrehovsky do you think the trimming is aggressive? should preserve EventSource event metadata. The [DynamicDependency] and [UnconditionalSuppressMessage] attributes on LoggingEventSource may not be sufficient under aggressive trimming?
MichalStrehovsky commentedon Apr 28, 2026
The core invariant we have for trimming is that if no trimming warnings are generated, the code needs to work. The test itself doesn't seem to be triggering trimming warnings. The trimming analyzer on the test itself is enabled (default value is now enabled and I don't see
<EnableTrimAnalyzer>false</EnableTrimAnalyzer>in this test project; there is a<EnableAotAnalyzer>false</EnableAotAnalyzer>in the test project but that's irrelevant for non-native AOT testing). So if there was a trimming issue in the test code itself, the analyzer would warn and break the build.So if the test is hitting issues after trimming, it's a product bug. We likely put
[UnconditionalSuppressMessage]on something in the product that is not actually safe with trimming. We either need to make it safe, or do a breaking change and declare this library as not compatible with trimming so that users get a proper build time warning when using it.MichalStrehovsky commentedon Apr 28, 2026
What a coincidence - looks like the test is using Newtonsoft JSON (😕) and we just picked up an upgrade to Newtonsoft JSON that marks all the APIs as trimming incompatible. This is now triggering a warning in this test:
e5aac86
It is not clear to me if this is related (I don't know about EventSource or logging), but could be. Would be nice not to use Newtonsoft as a general hygiene. Then we'd also know better if this is a product bug or not.
Fix trimming test exclusions for iOS/tvOS simulator CoreCLR builds (#…
Fix trimming test exclusions for iOS/tvOS simulator CoreCLR builds (#…