Summary
Surfaced by the new mobile-heads CI added in #511 (PR #519), specifically the TodoApp.Avalonia.iOS build:
Warning: .../samples/todoapp/TodoApp.Avalonia/TodoApp.Avalonia/Services/LoggingHandler.cs(28,33):
warning CS8604: Possible null reference argument for parameter 'content' in
'Task LoggingHandler.WriteContentAsync(HttpContent content, CancellationToken cancellationToken = default(CancellationToken))'.
This is a pre-existing nullable-reference warning, not something introduced by #511/#519 - it just hadn't been surfaced by CI before since /samples had no CI coverage until Phase 1 (#509).
Root cause
samples/todoapp/TodoApp.Avalonia/TodoApp.Avalonia/Services/LoggingHandler.cs:
protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
{
...
await WriteContentAsync(request.Content, cancellationToken); // request.Content is HttpContent?
...
await WriteContentAsync(response.Content, cancellationToken); // response.Content is HttpContent?
...
}
private static async Task WriteContentAsync(HttpContent content, CancellationToken cancellationToken = default)
{
if (content != null)
{
Debug.WriteLine($"[HTTP] >>> {await content.ReadAsStringAsync(cancellationToken)}");
}
}
HttpRequestMessage.Content and HttpResponseMessage.Content are both HttpContent? (nullable), but WriteContentAsync's content parameter is declared as non-nullable HttpContent. The method already null-checks internally (if (content != null)), so the nullable annotation on the parameter is simply wrong/stale - the compiler is correctly flagging that callers can pass null even though the signature claims they can't.
Only line 28 (request.Content) is called out in the log because MSBuild only reported the first occurrence per build, but response.Content on line 32 has the identical issue.
Suggested fix
Change the parameter to nullable to match actual usage:
private static async Task WriteContentAsync(HttpContent? content, CancellationToken cancellationToken = default)
No behavior change - the method already handles null correctly.
Impact
Low - this is a warning, not a build-breaking error (this repo does not set TreatWarningsAsErrors anywhere), so it doesn't currently fail any CI job. Worth cleaning up since it will otherwise show up as noise in every TodoApp.Avalonia mobile/desktop CI build going forward (build-samples-todoapp-avalonia.yml, all three jobs) now that #511 covers all of that sample's heads.
Related
Summary
Surfaced by the new mobile-heads CI added in #511 (PR #519), specifically the
TodoApp.Avalonia.iOSbuild:This is a pre-existing nullable-reference warning, not something introduced by #511/#519 - it just hadn't been surfaced by CI before since
/sampleshad no CI coverage until Phase 1 (#509).Root cause
samples/todoapp/TodoApp.Avalonia/TodoApp.Avalonia/Services/LoggingHandler.cs:HttpRequestMessage.ContentandHttpResponseMessage.Contentare bothHttpContent?(nullable), butWriteContentAsync'scontentparameter is declared as non-nullableHttpContent. The method already null-checks internally (if (content != null)), so the nullable annotation on the parameter is simply wrong/stale - the compiler is correctly flagging that callers can passnulleven though the signature claims they can't.Only line 28 (
request.Content) is called out in the log because MSBuild only reported the first occurrence per build, butresponse.Contenton line 32 has the identical issue.Suggested fix
Change the parameter to nullable to match actual usage:
No behavior change - the method already handles
nullcorrectly.Impact
Low - this is a warning, not a build-breaking error (this repo does not set
TreatWarningsAsErrorsanywhere), so it doesn't currently fail any CI job. Worth cleaning up since it will otherwise show up as noise in everyTodoApp.Avaloniamobile/desktop CI build going forward (build-samples-todoapp-avalonia.yml, all three jobs) now that #511 covers all of that sample's heads.Related