Previews, as seen when this build job started (e3d8478):
WebGPU _{webgpu.idl | Explainer | Correspondence Reference}
WGSL _{grammar.js | wgsl.lalr.txt}

I have some concerns about introducing this pattern because I couldn"t find another instance in WebGPU where we have both an early reject and a device timeline validation error.

Yes, we do it for all of the device-timeline error cases of mapAsync (which is most of them):

1. Issue the map failure steps on contentTimeline.
2. Generate a validation error.
3. Return.

I have some concerns about introducing this pattern because I couldn"t find another instance in WebGPU where we have both an early reject and a device timeline validation error.

Yes, we do it for all of the device-timeline error cases of mapAsync (which is most of them):

1. Issue the map failure steps on contentTimeline.
2. Generate a validation error.
3. Return.

None of those are early rejection cases on the content timeline that I"m aware of. I couldn"t find any early rejection cases on the content timeline which also generate a device validation error on the device timeline.

Ah, on the content timeline, no, I think this is the first where the spec actually specifies that. But since the errors are always delivered asynchronously, to an application the timeline barely matters - the only observable behavior difference is whether a .then callback resolves in a microtask off the current task, or later in a regular task. I think it"s more important to have consistent behavior across different error scenarios of mapAsync.

As for the implementation burden, there are several places where I think in practice an implementation needs to have a way to InjectError anyway, for example in writeTexture to avoid copying the entire source buffer to the GPU process (which is very important):

• Spec: "Note: This is described as copying all of data to the device timeline, but in practice data could be much larger than necessary. Implementations should optimize by copying only the necessary bytes."
• Chromium: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/webgpu/gpu_queue.cc;l=590;drc=6cb2176f96f60e90492d1bf8364cf5203652dde4?q=InjectError f:blink/renderer/modules/webgpu&ss=chromium

There are also several places where I think in practice an implementation needs to have a way to InjectError anyway, for example in writeTexture to avoid copying the entire source buffer to the GPU process (which is very important):

• Spec: "Note: This is described as copying all of data to the device timeline, but in practice data could be much larger than necessary. Implementations should optimize by copying only the necessary bytes."
• Chromium: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/webgpu/gpu_queue.cc;l=590;drc=6cb2176f96f60e90492d1bf8364cf5203652dde4?q=InjectError f:blink/renderer/modules/webgpu&ss=chromium

Indeed, we can inject the error and we do this in other places (such as GPUQueue.writeBuffer/writeTexture in the above case).

My primary concern is more the uniqueness to the early rejection and combined device timeline error. But perhaps the argument is, apologies if already stated, having this early rejection + validation error is preferable over simply having an early rejection?

Initially, I was not convinced the new pattern warrants the likely zero impact breaking change. But if we think this provides greater consistency, I am happy to switch my review to an approval ✅

Thanks!