rosbag2 playback rejects messages after type definition evolves

Symptom

After recording a bag with rosbag2 using a message definition (e.g., geometry_msgs/msg/PoseStamped), modifying that message type—such as adding a new field—and rebuilding the workspace causes playback to fail with a type hash mismatch. The bag stores serialized bytes and a type hash computed from the original definition; the new definition produces a different hash, so the reader rejects the data.

Context

The goal is to replay historical bags against updated message types without maintaining parallel type definitions. ROS 2’s type hashing is intentional for safety, but it creates a practical barrier when message schemas evolve in long-lived projects. The bag metadata (visible via rosbag2 info) shows the stored hash, yet there is no built-in migration path or compatibility layer in rosbag2 itself.

Open questions

• Is there a supported workflow to register a type adapter or custom deserializer that allows the new definition to consume old serialized bytes?
• Can the type hash check be relaxed or overridden for specific topics during playback without forking rosbag2?
• What is the recommended practice for versioning message types in a fleet where bags must remain replayable across releases?