GPUQueue.writeBuffer Retry After Device Loss: Missing Idempotency Guarantee

GPUQueue.writeBuffer Retry After Device Loss

The WebGPU API treats GPUQueue.writeBuffer and GPUQueue.submit as fire‑and‑forget. When a GPUDevice becomes invalid—either by device.destroy() or an implementation‑triggered loss—all queued writes are orphaned. The GPUDevice.lost promise resolves with a GPUDeviceLostInfo, but the spec provides no guarantee that prior writes have been applied or that they can be safely replayed without duplication.

Consequently, an application cannot, from the API alone, ascertain whether a write that occurred before a loss reached GPU memory. The absence of a write‑ahead log or durable acknowledgement means that blindly retrying the same writeBuffer after a loss may duplicate data, while an overly conservative approach would require re‑building state from a separate source of truth.

Key questions remain:

• Does GPUQueue.onSubmittedWorkDone() resolve only after all preceding writes and submits have finished, or can it settle before a loss is detected?
• Is there a reliable way to detect that a pre‑loss writeBuffer actually reached GPU memory?
• Can an application safely retry a writeBuffer after a lost event without risking duplicate writes, or must it rely on higher‑level idempotency logic?