Render Recovery release note

[atlv24]

Objective

• Completes goal and closes Render Recovery #23029
• Culmination of Render Recovery #22761, init_gpu_resource #23350, Reduce panics in rendering code to facilitate render recovery #23349, recovery fallback image #23433, Clear view upscaling pipelines on render recovery #23458, Move extra_buffer_usages to MeshAllocatorSettings #23444, Add IndirectParametersBuffersSettings #23459, Add needs_shader_reload to PipelineCache #23461, render asset recovery #23463, RenderCreation refactor #22714, Minor Render init refactor #22759, cleanup bevy_render/lib.rs #16481

Solution

• Add a release note.
• Re-export a wgpu type that you need to match on to handle errors.

Testing

• cargo run --example render_recovery with all the other PRs merged in. Press 5 and then V, the app will not crash. Note that D for "destroy device" will still crash: this is a WGPU problem resolved by Make get_mapped_range return a Result rather than panicking gfx-rs/wgpu#9281.

Note

I opted not to change the default recovery behavior yet. I believe we need testing in user projects and just general trodding of this code path before committing to a new default. It works in a simple example, it might not work in a complex project. We need to field test this and likely iterate to really call this ready IMO.

[NthTensor]

This is so cool! Idle question, in the long term are we thinking maybe we can throw a catch_unwind on top of the render world runner and fully drop+restart the render world in the event of a fatal panic?

[tychedelia]

I might add a brief note about when such failures can occur in practice and mention that this is intended for advanced users.

[alice-i-cecile]

Running the render_recovery example, pressing 5 then D on my machine crashes the app. L hangs the app, but that's probably fine. I could still close it.

Trying again with cargo run --example render_recovery --features="debug", the panicking system is: bevy_render::run_render_schedule.

thread 'Compute Task Pool (18)' (110793) panicked at /home/alice/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wgpu-28.0.0/src/backend/wgpu_core.rs:2231:18:
Error in Buffer::get_mapped_range: Validation Error

Caused by:
  Buffer with 'clustering metadata staging buffer' label has been destroyed

Device info:

2026-03-23T22:51:59.953837Z  INFO bevy_diagnostic::system_information_diagnostics_plugin::internal: SystemInfo { os: "Linux (Pop!_OS 22.04)", kernel: "6.17.9-76061709-generic", cpu: "13th Gen Intel(R) Core(TM) i9-13900K", core_count: "24", memory: "31.1 GiB" }
2026-03-23T22:52:00.006843Z  INFO bevy_render::renderer: AdapterInfo { name: "NVIDIA GeForce RTX 2060", vendor: 4318, device: 7817, device_type: DiscreteGpu, device_pci_bus_id: "0000:01:00.0", driver: "NVIDIA", driver_info: "580.119.02", backend: Vulkan, subgroup_min_size: 32, subgroup_max_size: 32, transient_saves_memory: false }

[alice-i-cecile]

Ah, known issue. Sure, I can live with that.