API footgun: shared_ptr to timer, ambiguous reset

[matthews-jca]

Generated by Generative AI

No response

Operating System:

Linux JCAPC214 6.8.0-107-generic #107-Ubuntu SMP PREEMPT_DYNAMIC Fri Mar 13 19:51:50 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

ROS version or commit hash:

humble, rolling

RMW implementation (if applicable):

No response

RMW Configuration (if applicable):

No response

Client library (if applicable):

rclcpp

'ros2 doctor --report' output

No response

Steps to reproduce issue

rclcpp::TimerBase::SharedPtr timer =
  node->create_wall_timer(1s,  {
    RCLCPP_INFO(rclcpp::get_logger("test"), "tick");
  });

// Intended: restart the timer
timer->reset();

// Accidental change during refactor:
timer.reset();  // Timer is destroyed instead

Expected behavior

Likely requires a refactor to the api to make the reset_timer explicit and not collide with the pointer

Actual behavior

Your pointer is reset and needs to be reconstructed

Additional information

No response

[fujitatomoya]

I'd push back on calling it a footgun in rclcpp's API, and disagree that this is an rclcpp API problem. this is just how std::shared_ptr works.

[matthews-jca]

I think it's worth noting that its a place that is very easy to get wrong and have things fail, and where their would be room for "if the api differed slightly, it'd be more clear and unambiguous" which to me says footgun. When we found the issue in our codebase on a rarely exercised timeout handler, it certainly felt like we'd shot ourselves in the foot.

[iv461]

There was another issue where somebody else had seemingly made the same mistake: #2765
But you cannot do anything except to change the entire API so that it no longer requires shared_ptrs for entities (e.g. use PIMPL like ROS 1).