Bevy 0.13 raw World resource access bypasses scheduler exclusivity enforcement

Direct Answer

Bevy 0.13+ does not provide compile-time or runtime detection for raw World::resource_mut calls that bypass the scheduler. Because the scheduler only tracks access declared via SystemParam (such as ResMut<T>), direct calls to the World API are invisible to the ECS exclusivity enforcement and the debug ResourceAccessTracker.

Synchronization Requirements

When a custom thread or async task mutates a resource that is also accessed by scheduled systems, you must implement your own synchronization. Bevy's internal scheduler cannot arbitrate access to the World once you have a raw reference to it outside of a system's execution context.

To safely mutate a resource from a custom thread while systems are running, use one of the following patterns:

• Interior Mutability: Wrap the resource data in a std::sync::Mutex<T> or RwLock<T>. The system should then request Res<Mutex<T>> and lock it manually.
• Command Buffers: Instead of direct mutation, send a custom event or use a channel to communicate with a system that has scheduled ResMut access.
• Exclusive System Access: Perform the mutation within a system that takes &mut World, which ensures the scheduler has paused all other systems.

Likely Explanation and Risk Profile

The World API is designed to be the "source of truth" and provides the primitive methods that SystemParam eventually calls. While ResMut acts as a borrow-checker for the scheduler, World::resource_mut is a direct access method. In Bevy 0.13, the stricter parallelism checks apply to the scheduling of systems, not to the World object itself once it is accessed outside the scheduler.

Risk: Calling World::resource_mut concurrently with a system holding ResMut for the same type is a data race. This may result in undefined behavior or crashes, and it will not trigger a Bevy runtime panic because the ResourceAccessTracker only monitors the scheduler's requested access.

Verification Steps

To verify your synchronization is working, you can use the following approach:

1. Wrap your resource in a Mutex: struct MyResource(Mutex<Data>);
2. Attempt to lock the mutex from both a custom thread and a system.
3. Run the application with a data-race sanitizer (e.g., using TSAN on supported platforms) to ensure no concurrent unsynchronized access occurs.

Diagnostic Detail Needed: Are you accessing the World via a NonSend resource or through a shared Arc<World> wrapper? This determines if the risk is limited to data races or extends to thread-safety violations.