Hi,

Current webgpu specs does not guarantee any ordering of promises related to device lost.

I noticed that with following steps it is possible to cause a race condition which prevents graceful device lost handling

1: Call "mapAsync" on buffer
2: Call "destroy" on device (Step 1 and 2 can be in other way around also)
3: The promise returned from "mapAsync" is getting rejected with message "Buffer is unmapped before the mapping is resolved" (on chrome). This is because device destroy will cause all mapped buffers to close.
4: The "device.lost" promise is resolved.

To handle graceful device lost, the step 4 should always happen before step 3.

If mapAsync is allowed to to get rejected before device.lost promise resolves, then code that handles the "mapAsync" rejection cant know that rejection was caused by lost device. This leads to situation where rejection handler cannot know if there is a severe bug in program or should the rejection be ignored for graceful handle the device lost.

Had the device.lost promise handler gracefully handled the device lost and requested a new device, there is a problem that before the graceful handle could happen, the rejection from "mapAsync" could show error for user or stop the program, depending on how errors are handled.

Other way to resolve this issue would be clear indicator in rejection from "mapAsync" which tells that the rejection was happened because of device lost rather than calling unmap or destroy the buffer from some other parts of code.