orcasound/orcahello

GetDetectionsAsync repeats the request, header parsing, deserialization and error handling that the queue methods already implement, and the copies have started to drift. Extracting one shared helper keeps pagination metadata and failure behavior consistent. Deferred from a #641 review round.

Opening the Dashboard can terminate the Blazor circuit and leave the yellow error bar. On a local run it happens on a cold page load, both from the sidebar and from a direct /Dashboard load. It is not unconditional: production is fine, and reloading the same page with Chart.min.js already in the browser cache is fine too. From the UI log: Microsoft.JSInterop.JSException: Chart is not defined ReferenceError: Chart is not defined at DrawDetectionsChart (<anonymous>:17:9) at AIForOrcas.Client.Web.Pages.Dashboard.LoadMetrics() in Dashboard.razor.cs:line 46 at AIForOrcas.Client.Web.Pages.Dashboard.OnInitializedAsync() in Dashboard.razor.cs:line 22 What I measured on a local run: Cold load: the circuit goes down, and typeof window.Chart is "function" a few seconds later. The library does arrive, just after the call that needs it. Same page reloaded, script in cache: no crash, both charts draw. Production: Chart defined, both charts draw, no console errors. Dashboard.razor loads

Building both ModeratorFrontEnd solutions on main with the .NET 8 SDK gives 0 errors and 129 warnings. OrcaHello.sln has 79, all from nullable reference analysis (CS8600 through CS8625, plus CS8618), concentrated in OrcaHello.Web.Shared and the DataMigration console: nulls passed into non-nullable parameters, uninitialized non-nullable properties, possible null dereferences. AIForOrcas.sln has 50, all CS1591: public members in AIForOrcas.DTO without XML comments, in a project that has documentation generation turned on. None of it blocks the build, but at this volume a new warning introduced by a PR disappears into the noise. Getting to zero would let warnings mean something again, and the nullable ones are the kind that occasionally point at a real bug.

The fix in #606 covered Candidates, but the same shape exists on the other three detection pages. In Confirmed.razor.cs, Unknown.razor.cs and FalsePositives.razor.cs the ActOnSubmitCallback calls LoadDetections() without clearing detections first, while the page-change and filter-change callbacks on those pages do clear it. The bottom pagination component only checks detections != null && detections.Count > 0, so a reload that comes back empty leaves the previous list's pager rendered under the no-records message. Seen live on the Confirmed page: re-moderating the last confirmed detections to No empties the list and the pager stays under the message. Unknown and False Positives share the same code path. To reproduce: on any of the three pages, filter down to a single page of results and re-moderate the last record so it leaves the list. Same symptom as #605, same one-line fix as #606: move the clear to the top of each page's LoadDetections() and drop the per-callback clears.

Support for .NET 8 will end on 10 November 2026. Please transition to .NET 10 by that date.   Your Azure Function Apps will continue to operate, but security updates will no longer be provided, and support for .NET 8 on Azure Functions will end. Running Function Apps on an unsupported runtime or language version might lead to security and performance issues. Upgrade to .NET 10 before 10 November 2026 to remain on a supported version. Learn more about Azure Functions stack version support. Recommended action  To avoid potential security vulnerabilities, minimize risk for your Azure Functions apps, and take advantage of latest features, you must take action based on your current configuration: If your app is using the in-process model: Migrate your app to the isolated worker model, then upgrade to .NET 10. For guidance, see: • <Migrate C# Apps from In-Process to Isolated Worker Model> • <Update Language Versions in Azure Functions> If your app is already using the isola