unwrap() fails in an AssetServer::update_asset_storage() if two assets are registered with the same uuid

[TheLeonsver1]

How can Bevy's documentation be improved?

The unwrap here:

bevy/crates/bevy_asset/src/asset_server.rs

Lines 501 to 503 in 43d99bb

	let channel = asset_lifecycle
	.downcast_ref::<AssetLifecycleChannel<T>>()
	.unwrap();

fails when two asset types are registered with the same UUID, the stack trace of the crash isn't assisting a lot in understanding why that might happen. I would like it If it could be documented.

[alice-i-cecile]

My first impression is that this could be improved by changing the unwrap to an .expect with a useful error message. It looks like this should fail if the downcast_ref results in the boxed value not actually being of the appropriate type.

In this case, that means a failure in type registration: I suspect you'll get a panic at the same place if you fail to register it at all.

[alice-i-cecile]

@TheRawMeatball points out that this core issue of duplicate type registration can (and should) first be caught at the add_asset call here. Following the chain, it looks like this is actually an issue with register_type, which should fail around here if a duplicate exists. IMO this should be a Result, but I'm not sure that plays nice with our builder pattern API for App...

That said, even improving the panic with a real error message would help folks debug.

[ShadowCurse]

Hi everyone. I have looked into this issue and it seems that problem lies here. Basically when we register a new asset type there is no check if entry with the same UUID exists. If two types have the same UUID, the later type will overwrite the previous one. This is why downcast_ref fails later.
I think a simple check with an error message would be fine for now.
Something like this:

if self.server.asset_lifecycles.read().contains_key(&T::TYPE_UUID) {
    panic!("Asset with UUID: {:?} already registered. Can not register another type with the same UUID", T::TYPE_UUID);
}