Skip to content

Re-key EventsCBGExecutor timers after a time jump (backport #3344) - #3403

Open
mergify[bot] wants to merge 2 commits into
jazzyfrom
mergify/bp/jazzy/pr-3344
Open

mergify[bot] wants to merge 2 commits into
jazzyfrom
mergify/bp/jazzy/pr-3344

Conversation

@mergify

@mergify mergify Bot commented Nov 9, 2026

Copy link
Copy Markdown
Contributor

Description

Fixes #3342

EventsCBGExecutor timers can stall after backward ROS time jumps or when use_sim_time is enabled at runtime because TimerQueue retains stale deadlines.

This PR uses the new schedule change callback from ros2/rcl#1352 to update timer deadlines. The callback only flags timers for rescheduling to avoid deadlocks.

test_executors_time_jump verifies both scenarios. It fails on Rolling and passes with both fixes.

Depends-On: ros2/rcl#1352

Is this user-facing behavior change?

Yes. Timers continue working after backward /clock jumps (e.g., ros2 bag play --loop --clock) and when use_sim_time is enabled at runtime.

Did you use Generative AI?

Yes. Claude Code (Claude Fable 5.1) assisted with investigation, implementation, and tests. Changes were reviewed and tested manually.

Additional Information

Reusing the on-reset callback causes a deadlock with TimeSource::set_clock().


This is an automatic backport of pull request #3344 done by Mergify.

rcl moves next_call_time of a ROS time timer when the clock jumps
back by more than one period and when ROS time is activated or
deactivated, without calling the on reset callback. TimerQueue keyed
its running timers by a copy of next_call_time taken when the timer
was added, fired or reset, so after such a jump the timer thread slept
until the stale deadline: a /clock jump from 1000 s back to 900 s
silenced a 100 ms timer for 100 s of simulated time, and a timer that
was created before use_sim_time was enabled never fired again.

Register rcl's schedule change callback on every ROS time timer. It
runs inside the clock jump callback with the clock mutex held, which
the timer thread takes while holding its wait mutex, so it only flags
the timer; the timer thread re-keys flagged timers before it computes
its next wakeup, and the flag is part of its wait predicate.

Signed-off-by: Yadunund Vijay <yadunund@gmail.com>
Signed-off-by: Alejandro Hernández Cordero <ahcorde@gmail.com>
Co-authored-by: Alejandro Hernández Cordero <ahcorde@gmail.com>
(cherry picked from commit ae09d1b)

# Conflicts:
#	rclcpp/src/rclcpp/executors/events_cbg_executor/timer_manager.hpp
#	rclcpp/test/rclcpp/CMakeLists.txt
@mergify mergify Bot added the conflicts label Nov 9, 2026
@mergify

mergify Bot commented Nov 9, 2026

Copy link
Copy Markdown
Contributor Author

Cherry-pick of ae09d1b has failed:

On branch mergify/bp/jazzy/pr-3344
Your branch is up to date with 'origin/jazzy'.

You are currently cherry-picking commit ae09d1b.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Changes to be committed:
	new file:   rclcpp/test/rclcpp/executors/test_executors_time_jump.cpp

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   rclcpp/src/rclcpp/executors/events_cbg_executor/timer_manager.hpp
	both modified:   rclcpp/test/rclcpp/CMakeLists.txt

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

Signed-off-by: Alejandro Hernandez Cordero <ahcorde@gmail.com>
@ahcorde

ahcorde commented Nov 10, 2026

Copy link
Copy Markdown
Contributor

Pulls: #3403
Gist: https://gist.githubusercontent.com/ahcorde/dd860f76c63a86a386ecaafbde76a0f2/raw/b332583718c33622cf66652a50f8de0928b7b2ef/ros2.repos
BUILD args: --packages-above-and-dependencies rclcpp
TEST args: --packages-above rclcpp
ROS Distro: jazzy
Job: ci_launcher
ci_launcher ran: https://ci.ros2.org/job/ci_launcher/21058

  • Linux Build Status
  • Linux-aarch64 Build Status
  • Linux-rhel Build Status
  • Windows Build Status

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants