Repository navigation
CTS expects wrong result of mapAsync on invalid buffer #4708
Description
On invalid buffer CTS expects:
and both firefox and chromium pass it, but spec says we should return abort and no validation error:
If any of the following conditions are unsatisfied:
this must be valid.
Set deviceLost to true.
Issue the map failure steps on contentTimeline.
Return.
If deviceLost:
Reject p with an AbortError.
This might also be spec issue as introduction PR of spec text talks about device loss, but here it's actually buffer invalidity part of code: gpuweb/gpuweb#5114 (this is buffer not device).
Activity
sagudev commentedon Sep 24, 2026
cc @kainino0x
kainino0x commentedon Sep 25, 2026
I think this is a spec typo, and it was meant to say
this.[[device]] must be valid.Right now, the spec says "if buffer is invalid, set deviceLost=true", which doesn't make any sense.
sagudev commentedon Sep 25, 2026
But we should still be check buffer validity, no?
EDIT: Usually we do https://www.w3.org/TR/webgpu/#abstract-opdef-valid-to-use-with, but maybe we want separate errors for device invalid vs. buffer invalid
sagudev commentedon Sep 25, 2026
there also does not seem to be any test for mapAsnyc on destroyed device
kainino0x commentedon Sep 25, 2026
Ah yes, true... probably accidentally missed that because the
this must be validof course makes it look like it is checked. It could also be the case that at some point I thoughtthis.[[internal state]] is "available"requirement would check that. It doesn't, though.Offhand I'm not sure, but you're probably right.
sagudev commentedon Sep 26, 2026
I prepared spec update gpuweb/gpuweb#10971 which raise AbortError (deviceLost=true) when device is invalid (lost) and raise OperationError on invalid buffer (in that order) as I think that was the original intention. Based on new CTS test this also matches the behavior of dawn.