This issue is a question/enhancement regarding the behavior of lifecycle nodes and their counterpart lifecycle entities (LifecyclePublisher and future lifecycle-enabled versions of subscriptions, services, action servers, etc.)

First, from the managed nodes design doc:

Primary State: Active
This is the main state of the node’s life cycle. While in this state, the node performs any processing, responds to service requests, reads and processes data, produces output, etc.

Similarly with other state guidelines in the documentation. the design outlines the expected behavior of a node in particular states. For the active state, all ROS communication is expected to be active and processing data. As it relates to ROS2 entities such as publishers, subscriptions, services, etc., this implies that their behavior would be in alignment with the lifecycle state of the node. To date, there only exists one lifecycle entity, the LifecyclePublisher, however with the introduction of a LifecycleService in #1838 / #1836, and the potential for lifecycle versions of subscriptions, action servers and more, the code is beginning to align better with the design documentation.

As of today, a LifecyclePublisher must be manually managed to activate/deactivate its state in a node. With the addition of new lifecycle entities to match the intended design, this management will only grow in scale/complexity as users will have to micromanage all entities for lifecycle transitions. My proposal in this issue is that instead of requiring user management of lifecycle entity activation/deactivation, allow the lifecycle node to automatically transition the state of its lifecycle entities (e.g. lifecycle publishers, subscriptions, services, etc.). Ignoring implementation considerations for now, this feature would ensure that lifecycle entity states (active/inactive) align with the lifecycle node, which already seems to be the intended design according to the documentation. This distinctly distinguishes lifecycle entities from the standard ones, since developers who don't anticipate to align their entities with lifecycle states would likely be well served by standard ones instead.

Benefits

• Reduce user micromanaging of lifecycle entities as components scale.
• Default behavior to that of intended best practice as recommended by managed node design documentation
• Implicit insight into state of lifecycle entities via query of lifecycle node state (e.g. an inactive lifecycle node also implies that lifecycle entities are inactive)

I welcome feedback discussing the merits or counterpoints to having this be the default behavior pattern for lifecycle nodes and its lifecycle entities.