API lacks handling for async ML device errors on the context

[bbernhar]

What happens if a WebNN operation dispatched through MLContext encounters some internal error which causes the GPU device to get removed?

I would expect WebNN to provide a spec into how fatal (device) errors are handled so the WebNN developer could respond appropriately. If we want to do more with MLContext (ex. create buffers), I believe we'll need a more robust error mechanism like WebGPU [1].

[1] https://www.w3.org/TR/webgpu/#errors-and-debugging

[bbernhar]

@anssiko this issue is for non-interop and still needs a follow-up proposal (low priority atm).

[zolkis]

Or, should we add plain error event(s) to MLContext?
Was there a specific design reason for the WebGPU type of error handling, i.e. not using error events, but tracking a promise on lost()?

After a device is lost (described below), errors are no longer surfaced. (...) Additionally, no errors are generated by the device loss itself. Instead, the GPUDevice.lost promise resolves to indicate the device is lost.

[inexorabletash]

A promise has slightly better ergonomics because (1) the transition to "lost" only happens once for a device, and (2) it works even if your code runs after the state has changed; you aren't forced to add an event listener immediately.

https://www.w3.org/2001/tag/doc/promises-guide#when-to-use

[anssiko]

@bbernhar if you agree with the general direction of the proposal #778 please feel free to close this issue to focus our attention.

[bbernhar]

@anssiko SGTM to move the discussion there.