Add control message payloads

[b3by]

Description

Nodes in Juturna are always supposed to produce message objects on their output channels, and similarly, they expect message objects on their input channels. Still, node threads use None as a termination signal. This behaviour may lead to confusion in cases where:

• None is part of the set of possible input/output values expected by/from a node;
• a source function in a source node produces null or empty values;
• messages should be propagated on the pipeline that trigger behaviours different from the stop;
• it is required to collect information about who triggered a pipeline stop.

This issues could be solved with the introduction of a new payload, that is only used internally by nodes to communicate control actions to take related with the pipeline execution and lifecycle.

Current Behavior

Nodes use None messages to stop their execution. No other actions can be triggered using messages.

Proposed Solutions

A new payload can be introduced, something like ControlPayload, to simply carry an enum value, where each one can be related with an action the nodes should perform (stop is an example).

---

This is a topic open for discussion.

[Ria-K912]

Hi @b3by, I’d like to take this issue and work on adding the ControlPayload implementation. Could you please assign it to me?

[b3by]

Hello there @Ria-K912, thank you for your interest in the project!

I am assigning this issue to you, but before you go on and start working on a solution that involves a new payload, as I initially suggested, maybe we could consider other solutions and potential use cases too.

After recent changes to the node base class, I realised the entire pipeline stop procedure (and maybe the start too) could probably be re-designed, as some of its original assumptions might no be respected, and there are certain aspects of the stop procedure that are worth checking for optimisation. I created separate issues for this, #46 and #47, so please check them out for potential chances coming!

[Ria-K912]

Thanks for the heads-up! I’ll check #46 and #47 first to understand the redesign scope and ensure any proposed payload changes fit well with the updated node structure.

[Ria-K912]

Hi @b3by,

I was reviewing this issue along with the related discussions, and I noticed that issue #48 can be resolved independently. I’ve raised a PR addressing it.

Whenever you get a chance, could you please review it?
Thank you!

[GaijinKa]

I'd like to propose a couple of interesting use cases for ControlPayloads:

• WARMUP message:
  A control payload that traverses the pipeline during the warmup phase, optionally triggering a dry run for each model.
  This ensures memory allocation and model initialization occur upfront during warmup, eliminating cold-start penalties on the first real inference request and improving overall startup performance.

• TURN_ON/TURN_OFF messages:
  Control payloads to dynamically enable or disable individual pipeline nodes at runtime, allowing them to switch between active processing and passthrough mode without requiring pipeline reconfiguration.

[b3by]

Hey @Ria-K912, thanks for wrapping up the PR #62. Regarding this issue: I'm going to unassign this for now. We need to push this feature forward fairly quickly, even if it still not clear to us what the actual timeline for it will look like, so I'm likely going to handle this one internally to align it with some other core changes we are making.

Thanks for your interest in it, I hope you'll keep the interest in the project going!