Fix timeout for no metadata run session

[Acuadros95]

Spin is not waiting if a session only haves timers, ending in a 100% CPU usage with code like this one: int32_publisher.

Also, we should run all sessions atleast once, to ensure a response to incoming data (From Hard liveliness check for example).

Related issue: #297

[github-actions]

Static memory analysis

Default configuration

MTU: 512 B
Input buffer size: 2048 B
Input history: 4
Output buffer size: 2048 B
Output history: 4

Entity	Qty	Size per unit
Context	2	5616 B
Topic	8	56 B
Service	4	248 B
Client	4	248 B
Subscription	4	280 B
Publisher	4	288 B
Node	4	208 B
Static input buffer	8	2136 B
Init options	6	64 B
Wait sets	4	56 B
Guard Condition	4	64 B

TOTAL: 34500 B

[Acuadros95]

@mergify backport humble iron

[mergify]

backport humble iron

🟠 Waiting for conditions to match

Details

• merged [📌 backport requirement]

[fallenmi]

This review was prepared with OpenAI Codex assistance under the account owner's authorization.

The new blocking fallback runs before guard conditions are inspected. Guard conditions do not mark an XRCE context as need_to_be_ran, so a wait set containing an already-triggered guard enters this branch whenever a session exists. uxr_run_session_timeout() is then given the full per-session timeout, and hasTriggered is not checked until after that call returns. With an infinite RMW timeout, this can wait indefinitely for unrelated XRCE traffic. rmw_trigger_guard_condition() only sets the flag, so a guard raised while this fallback is blocked cannot interrupt it either.

I compiled the exact production rmw_wait.c from the PR merge-base, exact head, current rolling, and GitHub's synthetic current merge against a deterministic session/guard oracle. With one session, an already-triggered guard, and a 5-second wait:

• merge-base 6833232797d1034860125e949f34067a850eeb43 and current rolling b6e02669d42fd5aeddc1e5b71bac65afd76cddf7 returned RMW_RET_OK after requesting a 0 ms session run;
• exact head 52f23f9a342ca35006325691a3d6cfe05ff8345f and synthetic merge 1fce9ed4782d8c4892cb20d7e1f45cac37446061 still returned RMW_RET_OK, but only after requesting a 5000 ms session run.

The existing guard-condition test checks only the eventual return code, so it does not catch this latency regression. Please preserve immediate guard delivery when adding the timer-only blocking behavior, and add a timing/wakeup regression for both a pre-triggered guard and a guard triggered during the wait.

[mergify]

backport humble iron

☑️ Command disallowed due to command restrictions in the Mergify configuration.

Details

• sender-permission >= write

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request