Delay after App::update triggers time_system warning
- Dominant language
- Rust
- Stars
- 48.2k
- Forks
- 4.8k
- Avg merge
- 3d 16h
- Merged PRs (30d)
- 171
Description
## Bevy version and features
424fc92
## What you did
Inserted a delay after the first `App::update`:
```rust
use bevy::prelude::*;
use std::time::Duration;
fn main() {
let mut app = App::new();
app.add_plugins(DefaultPlugins);
app.finish();
app.cleanup();
info!("first update");
app.update();
info!("sleep");
std::thread::sleep(Duration::from_secs(3));
info!("second update");
app.update();
info!("third update");
app.update();
info!("finish");
}
```
## What went wrong
This triggers a warning on subsequent update:
`time_system did not receive the time from the render world! Calculations depending on the time may be incorrect.`
Log from above program:
```log
2026-05-06T20:57:29.504339Z INFO bevy_diagnostic::system_information_diagnostics_plugin::internal: SystemInfo { os: "macOS 15.7.5 Sequoia", kernel: "24.6.0", cpu: "Apple M2 Pro", core_count: "12", memory: "16.0 GiB" }
2026-05-06T20:57:29.654801Z INFO bevy_render::renderer: AdapterInfo { name: "Apple M2 Pro", vendor: 0, device: 0, device_type: IntegratedGpu, device_pci_bus_id: "", driver: "", driver_info: "", backend: Metal, subgroup_min_size: 4, subgroup_max_size: 64, transient_saves_memory: true }
2026-05-06T20:57:30.485044Z INFO bevy_pbr::cluster: GPU clustering is supported on this device.
2026-05-06T20:57:30.485153Z INFO bevy_render::batching::gpu_preprocessing: GPU preprocessing is fully supported on this device.
2026-05-06T20:57:30.487017Z INFO bevtime: first update
2026-05-06T20:57:30.605932Z INFO bevtime: sleep
2026-05-06T20:57:33.606536Z INFO bevtime: second update
2026-05-06T20:57:33.619034Z INFO bevtime: third update
2026-05-06T20:57:33.619135Z WARN bevy_time: time_system did not receive the time from the render world! Calculations depending on the time may be incorrect.
2026-05-06T20:57:33.626585Z INFO bevtime: finish
```
## Additional information
It looks like during the first update, [time_system](https://github.com/bevyengine/bevy/blob/15540493a688e162e56b4ad19b6055fc35e109aa/crates/bevy_time/src/lib.rs#L146) receives an `TryRecvError::Empty` error, but `has_received_time` is false so no error is logged.
During the sleep delay, [send_time](https://github.com/bevyengine/bevy/blob/15540493a688e162e56b4ad19b6055fc35e109aa/crates/bevy_render/src/lib.rs#L481) is called from a compute task.
During the second `update`, `has_received_time` is set to true in `time_system`.
During the third `update`, `time_system` receives another `TryRecvError::Empty` error and logs the warning since `has_received_time` is now true.
Without the sleep delay, `time_system` receives `TryRecvError::Empty` during the first update, `has_received_time` is false.
During the second update, `time_system` receives `TryRecvError::Empty` again, `has_received_time` is still false. Then `send_time` is called from the compute task.
During the third update, `has_received_time` is set to true in `time_system`.
Contributor guide
Research direction
Reproduce the warning with the provided App::update example, then inspect time_system in crates/bevy_time/src/lib.rs and send_time in crates/bevy_render/src/lib.rs. Trace the channel timing across the first three updates and the render compute task. Done means the delayed updates no longer produce an incorrect time warning while time values remain correct.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- game-dev
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100