Warnings about 'Topic ... has unknown type' spam when specifying topics to be recorded which do not exist

[wjwwood]

Description

When asking rosbag to record a list of topics when some of those topics do not exist and some of those topics have unknown types results in continuous spam of messages like this:

[WARN] [1652302035.004255795] [ROSBAG2_TRANSPORT]: Topic '/some/topic' has unknown type 'msg_pkg/msg/SomeMessage' . Only topics with known type are supported. Reason: 'package 'msg_pkg' not found, searching: [/some/workspace/path/some_package, ...]

These messages are printed over and over again, despite there being some logic to try and only print it once per type:

rosbag2/rosbag2_transport/src/rosbag2_transport/topic_filter.cpp

Lines 154 to 170 in a076560

	bool TopicFilter::type_is_known(const std::string & topic_name, const std::string & topic_type)
	{
	try {
	auto package_name = std::get<0>(rosbag2_cpp::extract_type_identifier(topic_type));
	rosbag2_cpp::get_typesupport_library_path(package_name, "rosidl_typesupport_cpp");
	} catch (std::runtime_error & e) {
	if (already_warned_unknown_types_.find(topic_type) == already_warned_unknown_types_.end()) {
	already_warned_unknown_types_.emplace(topic_type);
	ROSBAG2_TRANSPORT_LOG_WARN_STREAM(
	"Topic '" << topic_name <<
	"' has unknown type '" << topic_type <<
	"' . Only topics with known type are supported. Reason: '" << e.what());
	}
	return false;
	}
	return true;
	}

Expected Behavior

This kind of error message is printed only once and does not spam the console while recording in this particular kind of scenario.

Actual Behavior

The error message is printed repeatedly.

To Reproduce

1. Run a publisher using a type not available to rosbag (either in another workspace or on another machine)
2. Ask ros2 bag record to record that topic and a topic that doesn't exist
3. Observe the error about the topic using a type unknown to rosbag is printed over and over

System (please complete the following information)

• OS: Ubuntu 20.04
• ROS 2 Distro: Rolling
• Version: 0.14.1

Additional context

I believe the issue is this logic for when multiple topics are requested but not immediately found:

rosbag2/rosbag2_transport/src/rosbag2_transport/recorder.cpp

Lines 175 to 194 in a060c1d

	void Recorder::topics_discovery()
	{
	while (rclcpp::ok() && stop_discovery_ == false) {
	auto topics_to_subscribe =
	get_requested_or_available_topics();
	for (const auto & topic_and_type : topics_to_subscribe) {
	warn_if_new_qos_for_subscribed_topic(topic_and_type.first);
	}
	auto missing_topics = get_missing_topics(topics_to_subscribe);
	subscribe_topics(missing_topics);
	if (!record_options_.topics.empty() && subscriptions_.size() == record_options_.topics.size()) {
	RCLCPP_INFO(
	this->get_logger(),
	"All requested topics are subscribed. Stopping discovery...");
	return;
	}
	std::this_thread::sleep_for(record_options_.topic_polling_interval);
	}
	}

This causes this function to be called in a loop:

rosbag2/rosbag2_transport/src/rosbag2_transport/recorder.cpp

Lines 196 to 202 in a060c1d

	std::unordered_map<std::string, std::string>
	Recorder::get_requested_or_available_topics()
	{
	auto all_topics_and_types = this->get_topic_names_and_types();
	TopicFilter topic_filter{record_options_, this->get_node_graph_interface()};
	return topic_filter.filter_topics(all_topics_and_types);
	}

Which as you can see instantiates a new TopicFilter every time, and the TopicFilter holds the state that checks if the warning should be printed again:

rosbag2/rosbag2_transport/src/rosbag2_transport/topic_filter.cpp

Lines 160 to 161 in a076560

	if (already_warned_unknown_types_.find(topic_type) == already_warned_unknown_types_.end()) {
	already_warned_unknown_types_.emplace(topic_type);

So the likely solution is to find a way to extend the lifetime of the TopicFilter instance.

[Jannkar]

Hey! Was this MR back-ported to Humble? I'm currently running rosbag2 version 0.15.7 in Humble, and I'm getting the console full of warning spam. This happens for topics that I'm not even recording, so could this be a combination of this spamming issue and #1444 ?

[MichaelOrlov]

Hi @Jannkar No. The fix hasn't yet been backported since backporting is not straightforward because it involves ABI changes.
See details in the #1434 (comment)

[Jannkar]

Thanks for letting me know!