Re-evaluate SUCCESS_IF and FAILURE_IF during RUNNING state

[facontidavide]

Summary

• Fixes Precondition not checked in ReactiveSequence #917 where _successIf and _failureIf preconditions were not re-evaluated when a node was in RUNNING state
• This prevented ReactiveSequence from responding to condition changes while an async action was running
• Now these preconditions are checked during RUNNING state, matching the existing behavior of _while

Changes

• Modified TreeNode::checkPreConditions() to also evaluate SUCCESS_IF and FAILURE_IF when status is RUNNING
• When a condition triggers during RUNNING, the node is halted and returns the appropriate status

Test plan

• Added test Issue917_SuccessIfWhenRunning - verifies _successIf halts running async action
• Added test Issue917_FailureIfWhenRunning - verifies _failureIf halts running async action
• All 336 tests pass

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes

  • Preconditions are now re-evaluated reactively during node execution, enabling dynamic interruption of running operations when conditions change.

• Tests

  • Added test coverage for precondition re-evaluation during node execution.

[coderabbitai]

📝 Walkthrough

Walkthrough

The changes enable reactive re-evaluation of preconditions (_successIf, _failureIf, and _whileTrue) while a node is in RUNNING state. Previously, preconditions were checked only at node startup; now they are continuously evaluated during execution, allowing nodes to transition to SUCCESS or FAILURE based on condition changes.

Changes

Cohort / File(s)	Summary
Precondition Reactive Evaluation src/tree_node.cpp	Expanded RUNNING branch to actively check SUCCESS_IF (return SUCCESS on true condition), FAILURE_IF (return FAILURE on true condition), and WHILE_TRUE (return SKIPPED when false). Preconditions now react dynamically during execution instead of remaining static.
Precondition Reactive Tests tests/gtest_preconditions.cpp	Added two test cases verifying that _successIf and _failureIf preconditions are re-evaluated when a node is RUNNING within a ReactiveSequence. Tests confirm condition state changes trigger appropriate node status transitions.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Poem

🐰 Hops excitedly

A node that runs and runs all day,
Now checks its conditions on the way,
When _successIf blooms into true,
It bounds to SUCCESS—what a breakthrough!
Reactive preconditions hop and dance,
Giving every node a second chance! ✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately and concisely summarizes the main change: re-evaluating SUCCESS_IF and FAILURE_IF preconditions during RUNNING state.
Description check	✅ Passed	The description covers all required elements: it fixes issue #917, explains what was changed and why, details the modifications to checkPreConditions(), lists the tests added, and confirms all tests pass.
Linked Issues check	✅ Passed	The code changes fully address issue #917 by modifying checkPreConditions() to re-evaluate SUCCESS_IF and FAILURE_IF during RUNNING state, and the added tests verify this behavior works correctly.
Out of Scope Changes check	✅ Passed	All changes are directly focused on fixing issue #917: the core logic change is in TreeNode::checkPreConditions() and the two new tests verify the specific behavior required by the issue.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/917-precondition-reactive-sequence

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
✅ +0.04% (target: -1.00%)	✅ 100.00%

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (2c71b41)	5395	3755	69.60%
Head commit (56115cb)	5402 (+7)	3762 (+7)	69.64% (+0.04%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#1101)	10	10	100.00%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 0.00%. Comparing base (2c71b41) to head (56115cb).
⚠️ Report is 4 commits behind head on master.

Additional details and impacted files

@@      Coverage Diff       @@
##   master   #1101   +/-   ##
==============================
==============================

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.