In my WasmEdge-based runtime, my WIT-shaped WebGPU ABI accepts raw sizes/offsets. In setting up my coverage-driven fuzzer, I discovered my host needs to reject invalid COPY_BUFFER_ALIGNMENT inputs before calling wgpuQueueWriteBuffer, wgpuCommandEncoderCopyBufferToBuffer, or submit. That is host-boundary validation, not a wgpu bug.
What does seem like an upstream bug is the abort behavior in wgpu-native: wgpuQueueSubmitForIndex calls handle_error_fatal, which panics inside an extern "C" path. That turns a validation failure into process abort across the Rust/C++ boundary. For embedders like me, that is a bit hostile and doesn't follow the rigor elsewhere.
If you'd like me to turn this into something more embedding friendly that's aligned with the rest of the norms in the project, I'm happy to send a PR.
In my WasmEdge-based runtime, my WIT-shaped WebGPU ABI accepts raw sizes/offsets. In setting up my coverage-driven fuzzer, I discovered my host needs to reject invalid COPY_BUFFER_ALIGNMENT inputs before calling wgpuQueueWriteBuffer, wgpuCommandEncoderCopyBufferToBuffer, or submit. That is host-boundary validation, not a wgpu bug.
What does seem like an upstream bug is the abort behavior in wgpu-native: wgpuQueueSubmitForIndex calls handle_error_fatal, which panics inside an extern "C" path. That turns a validation failure into process abort across the Rust/C++ boundary. For embedders like me, that is a bit hostile and doesn't follow the rigor elsewhere.
If you'd like me to turn this into something more embedding friendly that's aligned with the rest of the norms in the project, I'm happy to send a PR.