[✨ Triage] dotnet/aspire#15438 by EmilyFeng97 - [AspireE2E] An error “Cannot create a JSObjectReference from the val ...

[MihuBot]

Triage for microsoft/aspire#15438.
Repo filter: area-dashboard issues.
MihuBot version: 246635.
Ping MihaZupan for any issues.

This is a test triage report generated by AI, aimed at helping the triage team quickly identify past issues/PRs that may be related.
Take any conclusions with a large grain of salt.

Tool logs

dotnet/aspire#15438: [AspireE2E] An error “Cannot create a JSObjectReference from the value 'undefined'” occurs when quickly switching to details page and closing it by EmilyFeng97
Extracted 5 search queries: Cannot create a JSObjectReference from the value 'undefined' Blazor FluentDataGrid, FluentDataGrid JSObjectReference undefined when quickly opening/closing details page, Blazor JS interop error beginInvokeJSFromDotNet _invokeClientMethod Cannot create a JSObjectReference, race condition JSObjectReference undefined on component disposal or rapid navigation, FluentDataGrid/aspire-dashboard JSObjectReference error on quick navigation (regression 13.1.3/13.2.0)
Found 25 candidate issues

• aspnetcore#38517 (Nov 2021) - Blazor wasm: Reference Javascript function with IJSObjectReference
  Summary: Reported that attempting to obtain an IJSObjectReference to a JS function produced a JS exception. Investigation pointed to existing limitations in how JS values are classified/returned as IJSObjectReference (functions vs objects). The thread was closed as a duplicate of the broader interop tracking issue (31151). Relevance: shows historical constraints in what JS->IJSObjectReference calls accept and how that caused similar "Cannot create a JSObjectReference..." errors when the runtime rejected unexpected JS values.

• aspnetcore PR #62657 (opened Jul 10 2025, merged Jul 14 2025) - Enable IJSObjectReference to handle null/undefined values
  Summary: Implements a sentinel ({ __jsObjectId: -1 }) when DotNet.createJSObjectReference(null/undefined) is used, and updates the .NET JSON converter to treat that sentinel as null for IJSObjectReference?. This converts what used to be an exception into a successful (null) result and also updates disposal to skip the sentinel. Conclusion: this change directly addresses the class of error where a JS interop that is declared to return an IJSObjectReference gets undefined/null and previously threw "Cannot create a JSObjectReference from the value 'undefined'." Upgrading to a runtime that includes this PR should avoid exceptions when JS returns null/undefined.

• dotnet/aspire#759 (Nov 2023) - Error in dashboard after accidentally clicking "View" link for env vars on Executables page
  Summary: Very similar symptom: a FluentDataGrid import returned undefined when the dialog was closed quickly (double-click), leading to the same "Cannot create a JSObjectReference from the value 'undefined'." diagnosis found that the dialog was closed before the grid/module finished initializing and the JS side returned undefined. Steve Sanderson pointed to a pattern/workaround (and filed aspnetcore#52070 for improving this behavior). Conclusion: this is the same root class of race-condition + JS interop issue; the fix can be either in the component (guard against undefined / check for disposed state) or in the runtime (the PR above that treats undefined as null).

• aspnetcore#45777 (Dec 2022) - Blazor component removed from DOM before disposal causes js interop to fail
  Summary: Describes a race where DisposeAsync runs after the DOM element has already been removed so JS cleanup can fail. The guidance from the team: don't rely on Dispose/DisposeAsync to perform JS cleanup that assumes the element still exists; use MutationObserver or other patterns. Relevance: supports the diagnosis that prematurely-closing a dialog/details pane can make JS return undefined or fail — components should guard or use different cleanup strategies.

• aspire#2004 (Jan 31 2024) - Errors on the dashboard when navigating
  Summary: Error trace shows FluentDataGrid.OnAfterRenderAsync calls into JS and the import/interop returns undefined, producing the same exception. No discussion, but it's the same stack trace as your reproduction. Conclusion: this is a recurring dashboard/FluentUI data-grid interop failure when UI flow causes module/imports to be unavailable or return undefined.

• aspnetcore#40272 (Feb 16 2022) - InvokeAsync<IJSObjectReference?>() call does not return when js value is null or undefined
  Summary: Early report of the problem where InvokeAsync<IJSObjectReference?> thrown or otherwise failed when JS returned null/undefined. It was tracked for future evaluation; this is exactly the behavior the 2025 PR (62657) later fixed. Conclusion: historical signal that this was a known framework limitation that required runtime change.

• aspnetcore PR #61453 (Apr 11 2025, merged Apr 15 2025) - Enable getting IJSObjectReference to a JS function in Blazor interop
  Summary: Relaxed JS-side checks so functions can be returned as IJSObjectReference and added test coverage. Relevance: demonstrates ongoing refinements to how JS values are mapped to IJSObjectReference; while not directly about undefined, it shows the runtime has undergone several fixes in this area.

• aspnetcore PR #62840 (Jul 21 2025, merged Jul 28 2025) - Fixed race condition in the disposing of the QuickGrid
  Summary: QuickGrid had a race where OnAfterRender/JS module import and Dispose could interleave and cause errors. The PR adds a disposed flag and early exit checks in OnAfterRenderAsync and adds tests simulating the race. Conclusion: patterns used here (guarding OnAfterRenderAsync with a disposed flag, avoiding JS calls when disposing) are directly applicable to the dashboard components that call JS during render and can be disposed quickly.

• aspire#486 (Oct 2023) and aspire#741 (Nov 2023) - Dashboard exceptions on F5 after update / Lots of dashboard errors
  Summary: These Aspire issues report many JS interop errors during disposal (JSDisconnectedException) and disposal-time JS calls failing. The team traced these to FluentUI components calling JS during dispose and applied fixes in the FluentUI library. Conclusion: similar lifecycle/interoperability problems; fixes came from component-side guards and updated FluentUI package versions.

• aspnetcore#42423 (Jun 25 2022) - [JSInterop] Bug in DotNet.createJSObjectReference
  Summary: Bug report about DotNet.createJSObjectReference incorrectly rejecting function values because of a typeof check; discussion concluded the behavior was deliberate originally, but the thread is part of the general body of work improving JS<->.NET object references. Relevance: shows earlier classification mistakes that led to unexpected exceptions and motivated later changes.

• aspire#9559 (May 29 2025) - Dashboard error when clicking on Graph before components load
  Summary: Clicking graph tab before components have finished loading caused an error; likely caused by components invoking JS before modules were available. The issue was fixed in a later Aspire update (9.3.1). Conclusion: component-side load/availability checks can prevent the "undefined" faults you see.

• aspire#12356 (Oct 24 2025, closed Mar 11 2026) - Nightly tracing dashboard crashes
  Summary: Tracing UI showed many exceptions with ArgumentNullException: jsObjectReference was null while disposing FluentMenu. Team comment indicated the issue was resolved in Aspire 13.1. Conclusion: another example where rapid UI changes led to disposal and null/undefined JS references; upgrading to the fixed Aspire build resolved it in that case.

Overall takeaways / implications for the new issue:

• This error is a known pattern: a component makes a JS interop call (commonly in OnAfterRenderAsync or DisposeAsync) but the JS side ends up returning undefined/null because the component/dialog was closed or the module wasn't ready. Historically the framework threw an exception for undefined, but ASP.NET Core added a sentinel-handling change (PR #62657, Jul 2025) to treat undefined/null as null for IJSObjectReference? — upgrading to a runtime that includes that change should avoid many of these exceptions.
• There are also component-side mitigations that helped other Aspire/FluentUI issues: guard OnAfterRenderAsync and Dispose flows with an "is disposing/disposed" flag, check module/object != null before invoking, and avoid JS interop from Dispose that relies on DOM elements that may already be gone. The QuickGrid and FluentUI fixes are examples of this pattern.
• Short actionable checklist for triage of the new issue:
  • Confirm versions: which Aspire / Microsoft.AspNetCore / Blazor packages and runtime are in use. If older than the commits/PRs noted above, advise to try the runtime/package versions that include PR #62657 and the FluentUI fixes.
  • Reproduce and capture exact stack trace + timing (you already have that). Check whether the failing interop call is an import/getting module or a subsequent call returning undefined.
  • Try a local patch: in the component that triggers the data grid/details pane, add a guard to skip JS interop if the component/dialog is already closed/disposed or if the returned JS module/value is null/undefined.
  • If the problem still occurs with the updated runtime and FluentUI packages, collect a minimal repro and link it to the relevant aspnetcore issue (40272 / 52070 / 31151 where appropriate), but first try package/runtime upgrades and component-side guards since prior issues were fixed by both runtime changes and component fixes.

If you want, I can:

• point to the exact commits/versions containing PR #62657 and the FluentUI fixes, or
• prepare a short patch suggestion (guard pattern) that you can try in the dashboard component to prevent the exception.