Bug in asset loading

[torsteingrindvik]

Bevy version

Using git bisect show 57a175f as the commit which introduced the issue.
cc @bushrat011899

What you did

Run my Bevy app.

What went wrong

Panic in asset on getting infos.

For me it seems to relate to loading things within a gltf model- if I add some more logging around the bad unwrap I see the asset path is stuff like a Mesh1 or Animation1 within one of my gltf models.

Additional information

Other discord users hit the same issue:

https://discordapp.com/channels/691052431525675048/749332104487108618/1176633456835428453

That backtrace points to:

bevy/crates/bevy_asset/src/server/info.rs

Line 196 in 57a175f

let info = self.infos.get_mut(&id).unwrap();

which I have hit as well.

But I have also hit this one:

bevy/crates/bevy_asset/src/server/info.rs

Line 397 in 57a175f

.expect("Asset info should always exist at this point");

and the same discord user has hit this one:

bevy/crates/bevy_asset/src/server/info.rs

Line 410 in 57a175f

.expect("Asset info should always exist at this point");

[DasLixou]

Found it.
Your mentioned PR added hashing the typeid next to the asset id for Handles: https://github.com/bevyengine/bevy/blob/main/crates/bevy_asset/src/handle.rs#L225-L226
But the typeid is already hashed inside AssetId: https://github.com/bevyengine/bevy/blob/main/crates/bevy_asset/src/id.rs#L118-L119
So we are hashing the typeid 2 times for a typed asset id.
I wonder how the tests, which should assert that typed and untyped are the same didnt fail

[bushrat011899]

I'll start looking into this once I get home. That commit should only have a handful of observable changes that could even be the cause of any change in behavior.

[bushrat011899]

Found it.
Your mentioned PR added hashing the typeid next to the asset id for Handles: https://github.com/bevyengine/bevy/blob/main/crates/bevy_asset/src/handle.rs#L225-L226
But the typeid is already hashed inside AssetId: https://github.com/bevyengine/bevy/blob/main/crates/bevy_asset/src/id.rs#L118-L119
So we are hashing the typeid 2 times for a typed asset id.
I wonder how the tests, which should assert that typed and untyped are the same didnt fail

The UntypedAssetId and handle should have the exact same hashing function as the typed version, including hashing the type twice. If that is the cause, I'm even more confused.

[bushrat011899]

This looks like a race condition, likely the same one in #10688 Nope completely unrelated. Running alien_cake_addict multiple times in release mode (same binary) will produce anything from a crash on load, through to running the game correctly, through to not loading some of the models, etc.

[DasLixou]

Found it.
Your mentioned PR added hashing the typeid next to the asset id for Handles: https://github.com/bevyengine/bevy/blob/main/crates/bevy_asset/src/handle.rs#L225-L226
But the typeid is already hashed inside AssetId: https://github.com/bevyengine/bevy/blob/main/crates/bevy_asset/src/id.rs#L118-L119
So we are hashing the typeid 2 times for a typed asset id.
I wonder how the tests, which should assert that typed and untyped are the same didnt fail

The UntypedAssetId and handle should have the exact same hashing function as the typed version, including hashing the type twice. If that is the cause, I'm even more confused.

Really sorry to tell you:
https://github.com/bevyengine/bevy/blob/main/crates/bevy_asset/src/handle.rs#L395-L396
https://github.com/bevyengine/bevy/blob/main/crates/bevy_asset/src/id.rs#L283-L284
May the confusion be with you :>

[bushrat011899]

Below is an example of one of the times alien_cake_addict ran, but clearly failed to load assets: