The direct answer
No, there is no supported flag or per-topic override in rosbag2 to relax the type hash check, and no automatic schema-evolution layer. The supported path is a one-time conversion step: replay or relay the old bag through code compiled against the old message definition, republish with the new definition, and record a new bag. Anything that skips conversion and forces old bytes into the new type risks corrupt data, not just missing fields.
Why playback rejects the bag
From ROS 2 Humble onward, message types carry a RIHS01 type hash computed from the full definition. rosbag2 records that hash in the bag metadata (visible via rosbag2 info), and the type support layer refuses to deserialize when the subscriber's rebuilt type produces a different hash. This is deliberate: CDR serialization is not self-describing, so old bytes contain no marker saying "the new field is absent." If you bypassed the check, the deserializer would read past the end of the old buffer or misalign every subsequent field. The hash mismatch is protecting you from silent corruption.
What to do for this case
- Confirm the cause. Run
rosbag2 info <bag_dir> and compare the stored type hash for the topic against the hash of your current build's message. If they differ, the definition change is confirmed as the blocker.
- Keep the old definition available. Restore the pre-change
.msg into a legacy package (e.g., my_msgs_legacy) so both definitions build side by side.
- Write a small relay node that subscribes with the old type and republishes with the new type, filling added fields with explicit defaults. Play the old bag into it while running
rosbag2 record on the relay's output. The result is a new bag whose stored hash matches your current build.
- Verify by playing the new bag and checking the added field holds the expected default on every message.
Alternatively, the rosbag2 converter plugin framework or rosbag2_transport type adapters let you register conversion logic, but you still write the old-to-new mapping yourself — they are plumbing, not automatic migration.
Fleet practice going forward
Treat message definitions as immutable once bags are recorded against them. For breaking changes, version the message itself (MyMsgV2) or the package, and ship a documented migration tool that converts archived bags once. Reserve in-place field additions for cases where you accept running that migration per archive. Also note this guidance is distro-sensitive: strict RIHS01 hash checking applies from Humble onward; older distributions used weaker type-name matching, and this area is still evolving, so check your distro's rosbag2 release notes for any newly added conversion support before building tooling.
Uncertainty note: exact hash-check enforcement points and any newer converter APIs vary by ROS 2 distribution and rosbag2 release; verify against your installed version before relying on specifics.
ros