Summary
Awaiting Windows.Security.Credentials.UI.UserConsentVerifier.CheckAvailabilityAsync (and RequestVerificationAsync) through NSWinRT.toPromise terminates the process with a native v8 panic — a JS try/catch cannot intercept it:
[NativeScript] PANIC at v8-147.4.0/src/scope.rs:943:7:
v8::scope::PinnedRef<'_, v8::scope::HandleScope<'_, ()>> and Context do not belong to the same Isolate
Other WinRT asyncs on the same call path (StorageFile ops, PasswordVault ops) complete through toPromise without crashing, so this is specific to UserConsentVerifier's completion context.
Real-world use case affected
An app-level biometrics facade (@octane-xplat/biometrics) implementing Windows Hello verification on NativeScript Windows: biometrics.isAvailable() → CheckAvailabilityAsync, biometrics.verify(reason) → RequestVerificationAsync. Calling these from a packaged app's service/command context hard-crashes the process — the user sees the app silently die mid-operation, and no error surface (no rejection, no exception) reaches JavaScript.
Evidence
- Packaged MSIX
org.octanexplat.windows61 1.0.0.233, x64, on a NativeScript Windows preview runtime (Rust/v8 host; crash logged to nativescript-crash.log inside the package LocalState).
- Repro path: a polling command loop dispatched an async service spec on the app's JS thread; the spec's first
NSWinRT.toPromise(api.CheckAvailabilityAsync()) crashed. Earlier service specs in the same app using PasswordVault add/retrieve (also toPromise-awaited) completed normally.
- Working route: a managed C# helper enqueues
UserConsentVerifier calls on the captured DispatcherQueue and exposes a polled string state — that path works, but only because no WinRT async crosses NSWinRT.toPromise in JS.
Expected
toPromise resolves or rejects on the calling isolate; a class that cannot be awaited should fail safely (error or unprojected stub), never panic the process.