Inconsistent behaviour of spin_some after closing and reopening publisher

Bug report

Required Info:

• Operating System:
  • Pop!OS_20.04 LTS
• Installation type:
  • docker
• Version or commit hash:
  • ros:foxy
• DDS implementation:
  • default
• Client library (if applicable):
  • rclcpp

Steps to reproduce issue

This bug (if it is a bug) is probably not exactly reproducible as is on every device. On my system, the steps are:

• Insert the following code into a ros2 package

#include <memory>

#include "rclcpp/rclcpp.hpp"
#include "std_msgs/msg/string.hpp"

using std::placeholders::_1;

class MinimalSubscriber : public rclcpp::Node
{
  public:
    MinimalSubscriber()
    : Node("minimal_subscriber")
    {
      subscription_ = this->create_subscription<std_msgs::msg::String>(
      "topic", 100, std::bind(&MinimalSubscriber::topic_callback, this, _1));
    }

  private:
    void topic_callback(const std_msgs::msg::String::SharedPtr msg) const
    {
      std::cout << "I heard: " << msg->data << std::endl;
    }
    rclcpp::Subscription<std_msgs::msg::String>::SharedPtr subscription_;
};

int main(int argc, char * argv[])
{
  rclcpp::init(argc, argv);
  rclcpp::Rate rate(1);

  auto node = std::make_shared<MinimalSubscriber>();

  while (rclcpp::ok()) {
    rclcpp::spin_some(node);
    rate.sleep();
  }

  rclcpp::shutdown();
  return 0;
}

• colcon build

On a terminal:
ros2 run issue subscriber

On a different terminal:

• ros2 topic pub /topic std_msgs/String "data: ciao" -r 1;
• Subscriber on the other terminal is receiving correctly;
• stop ros2 topic pub (CTRL+C)
• Play it again: ros2 topic pub /topic std_msgs/String "data: test" -r 1;

Expected behavior

Message is received again by the subscriber node on the second time ros2 topic pub is launched

Actual behavior

Message is not received the second time (and the next ones as well)

Additional information

I suspect this has something to do with the subscriber queue size and the node loop rate. At larger queue sizes (~100, 1Hz rate) this does not happen, nor with larger frequencies (at 100Hz, queue size 1). It does not seem to depend on the publishing rate.
NB: using spin() instead of spin_some() is not a solution for me.

Start at the rclcpp::spin_some entry point and reproduce the provided subscriber and publisher sequence, including closing and reopening the publisher. Trace why callbacks stop after the second publisher launch; done means the subscriber receives messages again without replacing spin_some with spin.