Bug report
SnapshotCapture creates its background subscriptions once, in the constructor. For each configured topic it asks the ROS graph for the type (get_topic_type in src/ros2_medkit_fault_manager/src/snapshot_capture.cpp). When the graph has no type yet, it logs
Cannot determine type for topic '<topic>', skipping background subscription
and moves on. Nothing tries again, so that topic has no background subscription for the life of the node, and a freeze-frame taken from the cache never carries it.
A fault manager that starts with the robot hits this whenever it comes up before the publisher it is configured to capture. The same happens for a node that restarts later.
Steps to reproduce
- Configure
snapshots.background_capture: true and a fault_specific or default_topics entry for a topic published by another node.
- Start the fault manager before that node.
- Confirm a fault that maps to the topic.
Expected behavior
The background subscription is created once the topic appears, and the freeze-frame carries the topic's last message.
Actual behavior
The warning above is logged at startup, no subscription is ever created, and the freeze-frame stays empty for that topic. The fault manager keeps running and reports nothing else about it.
Environment
- ros2_medkit version: main
- ROS 2 distro: humble, jazzy, lyrical
- OS: Ubuntu 22.04, 24.04, 26.04
Additional information
Measured in SnapshotCaptureTest.BackgroundCaptureCachesFreezeFrame, which creates the publisher on the same node and constructs SnapshotCapture right after: on two cores the type was missing in 10 of 20 runs. The test now waits for the graph. The node still takes whatever the graph holds at that one moment.
The opcua one-shot discovery issue (601) is the same shape in a different component: work done once at startup, with no second attempt when the graph is not ready yet.
Bug report
SnapshotCapturecreates its background subscriptions once, in the constructor. For each configured topic it asks the ROS graph for the type (get_topic_typeinsrc/ros2_medkit_fault_manager/src/snapshot_capture.cpp). When the graph has no type yet, it logsand moves on. Nothing tries again, so that topic has no background subscription for the life of the node, and a freeze-frame taken from the cache never carries it.
A fault manager that starts with the robot hits this whenever it comes up before the publisher it is configured to capture. The same happens for a node that restarts later.
Steps to reproduce
snapshots.background_capture: trueand afault_specificordefault_topicsentry for a topic published by another node.Expected behavior
The background subscription is created once the topic appears, and the freeze-frame carries the topic's last message.
Actual behavior
The warning above is logged at startup, no subscription is ever created, and the freeze-frame stays empty for that topic. The fault manager keeps running and reports nothing else about it.
Environment
Additional information
Measured in
SnapshotCaptureTest.BackgroundCaptureCachesFreezeFrame, which creates the publisher on the same node and constructsSnapshotCaptureright after: on two cores the type was missing in 10 of 20 runs. The test now waits for the graph. The node still takes whatever the graph holds at that one moment.The opcua one-shot discovery issue (601) is the same shape in a different component: work done once at startup, with no second attempt when the graph is not ready yet.