Bugzilla

Actually, it could also be related to [#6328](https://github.com/gfx-rs/wgpu/pull/6328), the fix to phony assignments:
https://github.com/gfx-rs/wgpu/issues/6095#issuecomment-2365021257

```typescript
    const module = t.device.createShaderModule({
      code: `
        @group(0) @binding(0) var s: texture_storage_2d<${format}, read>;
        @compute @workgroup_size(1) fn csWithoutStorageUsage() {
        }
        @compute @workgroup_size(1) fn csWithStorageUsage() {
            _ = textureLoad(s, vec2u(0));
        }
      `,
    });
```

Actually, it could also be related to [#6328](https://github.com/gfx-rs/wgpu/pull/6328), the fix to phony assignments:
https://github.com/gfx-rs/wgpu/issues/6095#issuecomment-2365021257

From the test case, we can see that the `csWithStorageUsage` entry point has a phony assignment:

```typescript
    const module = t.device.createShaderModule({
      code: `
        @group(0) @binding(0) var s: texture_storage_2d<${format}, read>;
        @compute @workgroup_size(1) fn csWithoutStorageUsage() {
        }
        @compute @workgroup_size(1) fn csWithStorageUsage() {
            _ = textureLoad(s, vec2u(0));
        }
      `,
    });
```

Before #6328, this phony assignment would have been removed entirely from the module by compaction. That removal was incorrect, because it affected the computation of the [interface of a shader](https://gpuweb.github.io/gpuweb/wgsl/#interface-of-a-shader). Thus, Firefox previously considered `csWithStorageUsage` *not* to use the storage texture `s`; after the wgpu update, it does.

The failure is expected [here](https://github.com/gpuweb/cts/blob/27f834bc4c4d3be81cdb40647e3a24ccbd3a5011/src/webgpu/compat/api/validation/render_pipeline/unsupported_wgsl.spec.ts#L197-L201):

```
    const isValid = !t.isCompatibility || entryPoint === 'csWithoutStorageUsage';
    t.doCreateComputePipelineTest(async, isValid, {
      layout: 'auto',
      compute: { module, entryPoint },
    });
```

Firefox does not support compatibility mode, so `isValid` is true, so `doCreateComputePipelineTest` is going to call `expectValidationError` and pass false for `shouldError`, directing it *not* to wrap the call to `createComputePipeline` in an error scope. This accounts for why the error is getting caught by `attemptEndTestScope`, as shown in the stack trace.