Robot Bag Loss Notes: Incremental Events and Total Claims

Bag Loss Notes in a robot service packet should distinguish an incremental event from a cumulative total. Rosbag2's documented loss events report per-topic losses since the previous event and omit topics with no reported losses. Reading one event as the complete recording inventory or the total loss over an entire incident would change that scope. This article reads the project's rolling-branch definitions and a fictional support packet. It records, replays and repairs no data.

Read the event interval in the recorder explanation

The official rosbag2 README describes statistics about messages lost in the recorder and transport layer. Its loss-statistics section says that the events are incremental and that internal counters reset after each event is published. That reset boundary belongs in a service summary of any supplied event.

For a fictional incident appendix, suppose a contributor copies one event into a table headed lifetime lost messages. The reviewer should ask what interval the event represents. The documentation supports an incremental reading, not an unqualified lifetime label. No actual recording duration or lost-message count is supplied here.

Keep per-topic entries attached to the event

The official MessagesLostEvent definition includes the sender's fully qualified node name and a list of per-topic statistics. Its comments repeat that the statistics concern messages lost since the last event. A detached topic count needs that event and sender context before it is summarized.

A fictional service table should therefore retain which event supplied a row. Several rows about the same topic in different events do not automatically duplicate the same cumulative total. Conversely, an isolated row does not explain whether earlier events were retained. This article performs no aggregation and does not construct a total from incomplete material.

Preserve the two documented loss counters

The official per-topic statistics definition gives separate messages_lost_in_transport and messages_lost_in_recorder fields. Each is described since the last event. A support export should retain those field identities rather than combine them under an unnamed loss column and leave the reader to infer the layer.

The fields locate the reported categories. They do not by themselves diagnose a network, disk or robot sensor. A real cause assessment needs the relevant system context and observations. This article has no counters to compare, no storage test and no evidence about the cause of any actual loss.

Do not read omitted topics as a complete inventory

Both the README and event definition say topics with no lost messages are not included in the event. An event is consequently not a list of every topic being recorded. A topic's absence from one event should not be rewritten as proof that it was never selected or that the sensor produced no data.

The qualification also does not turn an incomplete collection of event files into proof of loss-free recording. The reviewer needs to identify what material was retained and which period it covers. An omitted topic in a documented event and an entirely missing event are different evidence questions, even if both leave a blank in a shortened table.

For a fictional packet containing only a selected excerpt, a bounded note can describe the excerpt's actual fields and preserve the missing coverage account. It should not fill every absent topic with a fabricated row or assume that the chosen event covers the whole incident. The original material should remain available for further review.

Keep event publication separate from physical-data recovery

The README describes a maximum publication-rate option for these statistics. A frequency limit is not evidence that every possible event was retained in the support packet. This article selects no rate, enables no topic and makes no statement that an actual collector received a continuous event stream.

Loss statistics also do not reconstruct the missing message payloads. A service note can explain the reported loss scope while leaving data recovery as a separate, unsupported question. No message content has been recreated, and no repaired recording is offered by this document-reading exercise.

Write the support finding with its interval

A clear finding identifies the event source, topic, field and incremental interval, together with the known coverage of the submitted packet. If a later contribution supplies more events, preserve how they extend that coverage. Correcting a cumulative heading to an incremental one is a documentation revision, rather than evidence that lost data reappeared.

The cited source branch is rolling, read on November 5, 2026; another deployed version needs its applicable definitions. The original diagrams contain no real event times, counters or robot messages. Related reading appears in the robot service log category and recording reference category. Bag Loss Notes remain clearer when per-event increments and any separately established total retain their distinct scopes.