Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Support lifecycle-managed timers in rclcpp_lifecycle::LifecycleNode

Abierto
  • ¿Algo no está bien?
#3,255 7 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@armaho ya está trabajando en esto.

Desde el 10/9/2026.

  • #3263 de @armaho — abierto

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
30/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
cpp
Área
api

Línea de trabajo

Comienza con LifecycleNode::create_timer() y create_wall_timer(), y después revisa el comportamiento de las transiciones del ciclo de vida descrito aquí y el debate de diseño en PR #2261. Resuelve con los maintainers las preguntas abiertas sobre la API y el estado de transición; se considera terminado cuando haya una API de temporizadores gestionada por el ciclo de vida acordada y pruebas que cubran los estados inactivo y activo, las transiciones repetidas, la creación mientras está activo y las transiciones fallidas.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement
Description

rclcpp_lifecycle::LifecycleNode does not provide an API for managing timer callback execution based on lifecycle state.

Currently, LifecycleNode::create_timer() and create_wall_timer() create regular rclcpp timers whose callback execution is not managed by lifecycle transitions.
As a result, if an executor is spinning, timer callbacks may run even when the node is Unconfigured or Inactive.

This is not a claim that the existing timer APIs are incorrect.
The issue is that LifecycleNode does not provide an API for opting into lifecycle-managed timer behavior.

This issue proposes the following behavior for lifecycle-managed timers:

Lifecycle state or transition Proposed timer behavior
Unconfigured Do not start executing new timer callbacks
Inactive Do not start executing new timer callbacks
Successful transition to Active Start or resume callback execution for timers that have already been created
Active Allow lifecycle-managed timer callbacks to execute
Successful deactivation cancel() the timer; callbacks already in flight may complete
Successful cleanup / shutdown Prevent new timer callbacks from starting and clean up the timer

The start behavior for a timer created while the node is already Active, and the behavior when a lifecycle transition fails, are left as open questions below.

Motivation

Applications may need to control periodic timer-based work according to lifecycle state.
However, because LifecycleNode does not provide a lifecycle-managed timer option, each application must implement this control separately.

The ROS 2 Managed Nodes design describes Inactive as a state in which the node is not performing any processing.
The lifecycle_talker demo also uses a regular timer and includes a comment that a future version will add a timer following the same lifecycle management as a lifecycle publisher. This comment provides historical context that lifecycle-managed timers have been considered before.

Inspection of the LifecycleNode implementations in Rolling and Jazzy found that neither branch provides a separate lifecycle-managed timer API.
On Jazzy, I confirmed that callbacks from a regular create_wall_timer() execute while the node is both Unconfigured and Inactive.
This result demonstrates the current behavior of regular timers; it does not imply that the existing API violates an explicitly documented lifecycle contract.

Design / Implementation Considerations

There are three possible API directions to consider.

Add a new API

  1. Add separate APIs for creating lifecycle-managed timers.

Change the existing APIs

  1. Change the default behavior of LifecycleNode::create_timer() and create_wall_timer() so that they create lifecycle-managed timers.
  2. Add an option to the existing APIs for selecting managed or unmanaged behavior.

For now, I propose adding separate APIs.
Changing the default behavior of the existing APIs could alter timer behavior in Inactive without a compile error for existing applications that use auto or rclcpp::TimerBase::SharedPtr.
Adding an option would preserve existing calls, but the same function would provide different lifecycle behavior, requiring readers to inspect the option at each call site to determine whether a timer is lifecycle-managed.
Separate APIs would preserve existing application behavior while making the distinction between regular and lifecycle-managed timers explicit at each call site.

For example, the following APIs could be considered:

create_lifecycle_timer(...)
create_lifecycle_wall_timer(...)

To assess the feasibility of the proposed behavior, I tested a downstream implementation that calls cancel() and reset() on timers in response to lifecycle transitions.
The Jazzy-based tests confirmed that new callbacks did not start while the node was Inactive, callbacks executed while it was Active, and timer callback execution resumed across repeated activate/deactivate cycles.

This validation only establishes the feasibility of the proposed lifecycle behavior.
The actual upstream API names, signatures, return types, and internal management approach remain open for discussion with the maintainers.

PR #2261 proposed separate APIs for lifecycle-managed timers and integration with lifecycle transitions, but it was closed without being merged.
The review raised design questions about whether callbacks should execute before activation under different autostart settings and how a timer created while the node is already Active should behave.

This issue does not request adopting the implementation from #2261 as-is.
Its purpose is to clarify behavior based on lifecycle state and timer creation timing, and to revisit the API design for lifecycle-managed timers.

I would appreciate maintainer guidance on the following:

  1. Is lifecycle-managed timer support still desired for Rolling?
  2. Which direction would be preferable: adding separate APIs, changing the default behavior of the existing APIs, or adding an option to the existing APIs?
  3. If a lifecycle-managed timer is created while the node is already Active, should it start immediately?
  4. How should a managed timer behave when a lifecycle transition fails?
Additional Information

Lifecycle-managed timer support for rclcpp_lifecycle::LifecycleNode in Rolling

Lenguaje dominante
C++
Estrellas
814
Forks
572
Merge medio
4 d 8 h
PR fusionados (30 d)
18

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ros2/rclcpp

Todos los issues de ros2/rclcpp

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.