Description
Any dynamic-typed property read (occasionally also a write) can — unpredictably, not on every call — trap with a WASM unreachable instruction inside Elements’ own runtime, aborting the entire WASM instance. The DevTools console only ever surfaces a single truncated top frame:
Fatal exception in WebAssembly!
Exception: NullReferenceException: Member access on null reference
Uncaught {stack: RuntimeError: unreachable
at AlliedHealthClient.wasm-<hash>:wasm-function[1988]:0x120163), message: unreachable}
Capturing the exception via a page-level window.addEventListener('error', ...) (a local try/catch around the JS call that triggers the WASM work does not catch it — it surfaces later than that call returns) yields the full, multi-frame stack, e.g.:
RuntimeError: unreachable
at ElementsRaiseException
at ExternalCalls.RaiseException
at DynamicHelpers.GetMember
at DynamicView.OnLayoutLoaded <-- application code, one dynamic .property read
at DynamicView.Mount's closure (fLoadHandler)
at MessageHandler.Invoke
at MessageBus.Publish
at (JS/WASM boundary, imp.env.__island_invoke)
at System.WebAssembly.InvokeMethod
at System.Reflection.MethodInfo.Invoke
The application frame at the point of the trap varies between runs of identical code with identical input — observed in DynamicView.OnLayoutLoaded (reading .status/.data/.layout off a plain JS object), LayoutEngine.RenderStatCard (via the already-“safe” __ahGetProp bridge), LayoutEngine.ParseNode (a SetMember, not a GetMember), and LoginView.HandleSubmit (reading a login-form field — code that had already succeeded dozens of times earlier in the same session). All of these call sites are reached via the app’s “hidden trigger button + onclick +=” bridge pattern (see the App.pas remarks above WireBridgeTriggers), i.e. a delegate invoked through System.Reflection.MethodInfo.Invoke across the JS/WASM boundary — every observed crash is several frames below that reflection-based invoke.