DynamicScene fails to load after renaming a component field — old scene deserialization error in bevy_scene

Question

Scene deserialization failure after schema change
I'm using Bevy's DynamicScene (bevy_scene) to persist levels, and I'm hitting the fragility around schema changes. When a Rust component struct changes — say a field is renamed — old scene files no longer load.
My understanding is that the RON-based scene format resolves types and fields strictly: if a saved scene references a type or field that no longer matches the registered schema, deserialization errors out at load time rather than skipping the mismatch. That makes shipping updates risky, since any refactor of a reflected component can break existing saves.
I'm trying to decide between a tolerant loader and a strict one. I know #[reflect(default)] can supply defaults for newly added fields, but that doesn't seem to help when old data contains fields the struct no longer has.
Is there a documented way to make the scene loader tolerate missing or unknown fields, or is the intended pattern to wrap saves in a versioned envelope with dedicated serde structs and convert to components at load time? And if I keep DynamicScene, what is the recommended approach to migrate or reject old data deterministically — should I implement my own versioning layer on top of the scene format?

Tasadduq Burney · Answer

Bevy's DynamicScene does not provide a tolerant RON loader. The RON-based format matches fields by exact name and type ID, so renaming a reflected component field causes immediate deserialization failure. The documented and community-recommended pattern for schema evolution is to wrap scene data in a versioned envelope and map deserialized data into current components at load time.
Likely explanation vs confirmed facts
The research brief confirms that DynamicScene deserialization resolves types and fields strictly. Renaming a field breaks the name-to-index mapping, triggering an error rather than skipping the mismatch. The #[reflect(default)] attribute supplies defaults for newly added fields during serialization but does not tolerate old scene data containing renamed or missing fields.
Recommended migration strategy

Define a versioned envelope, e.g., a custom serde struct with a version field that mirrors your component layout.
  Deserialize into the envelope first, using serde defaults, renames, or optional fields to handle missing or renamed data.
  Migrate in code after deserialization: inspect the version field and transform the intermediate data into the current DynamicScene or directly into components before spawning.
  Reject deterministically: if a version is too old or migration is impossible, return a clear error instead of letting the RON parser fail with an opaque message.

Steps to verify and implement for your case

Open a saved .ron file and locate the component's type ID and the field name that was renamed.
  Write a minimal test: save a scene, rename the field in the Rust struct, attempt to load the scene, and capture the exact deserialization error (e.g., missing field old_name.
  Confirm the Bevy version you are using; the strict name-matching behavior is consistent from 0.10 through 0.12, but API internals may shift in later releases.
  Implement the versioned envelope and a migration function that runs before DynamicScene::deserialize.

One missing diagnostic detail
What Bevy version are you targeting? The exact error message and available reflection APIs can differ between minor versions, which may affect the migration implementation.

DynamicScene fails to load after renaming a component field — old scene deserialization error in bevy_scene

Scene deserialization failure after schema change

1 answer

Likely explanation vs confirmed facts

Recommended migration strategy

Steps to verify and implement for your case

One missing diagnostic detail

Your perspective belongs here.

0 question comments