asset server: hot reload of shaders crashes app

[c-antin]

Bevy version

0.8

Relevant system information

Rust 1.62.1
Windows 10

What you did

I tried to modify shaders at runtime and sometimes got the following error:

ERROR wgpu::backend::direct: Handling wgpu errors as fatal by default
thread 'Compute Task Pool (2)' panicked at 'wgpu error: Validation Error

Caused by:
    In Device::create_render_pipeline
      note: label = `opaque_mesh_pipeline`
    error matching VERTEX shader requirements against the pipeline
    unable to find entry point 'vertex'

I've created a repo to simulate the error here:
https://github.com/c-antin/bevy_asset_server_watch_for_changes_shader_bug

[IceSentry]

Is it possible that you saved the shader while it was invalid? The only times I've ever seen this was when I saved an invalid shader. Not crashing on invalid shader would be a solution, but I just want to make sure this is what's going on.

Also, can you add a license to you repo, we can't look at unlicensed code

[c-antin]

Is it possible that you saved the shader while it was invalid? The only times I've ever seen this was when I saved an invalid shader. Not crashing on invalid shader would be a solution, but I just want to make sure this is what's going on.

The shader is valid. In the example repo, it basically switches (file copy) between 2 valid shaders until the app crashes.

Also, can you add a license to you repo, we can't look at unlicensed code

Added a license.

[afonsolage]

I can confirm this issue. When you save your shader, sometimes it just panics with wgpu error: Validation Error and you just have to rerun the game and everything is fine.

Also noticed the higher the FPS, the higher the chance of this problem happening. Running without VSync, at ~400 fps it happens very often. At lower FPS, it is less likely to happen.

[JMS55]

I've run into this a lot lately, it's pretty annoying.

[mockersf]

It's the "known" issue of Bevy being notified as soon as the file is modified, and trying to load it then before the new content is written to disk.

This issue will depend on your OS, your code editor, your filesystem, your disk/ssd, ...

[JMS55]

Perhaps we could fix this by having bevy not immediately reload the content, wait Xms, and then check if it's changed again, and if so keep waiting?

[mockersf]

Yup that should probably work.

In this system https://github.com/bevyengine/bevy/blob/main/crates/bevy_asset/src/io/file_asset_io.rs#L177

• instead of immediately reloading file change, keep a local list of modified file and the last timestamp of the timestamp received
• when receiving an event, either add to the list for a new path, or update the timestamp for a path already in the list
• when the timestamp for an entry is older than Xms (configurable, maybe 500ms by default), remove the entry from the list and update it

I never managed to reproduce the issue, but that should work

If someone wants to tackle the issue, be sure to be able to reproduce first