Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add halt for flow, decorator and sync action nodes. #69

Merged
merged 20 commits into from
Jun 28, 2024

Conversation

samouwow
Copy link
Contributor

@samouwow samouwow commented Jun 26, 2024

This PR modifies the r_sequence and r_fallback flow nodes to call "halt" on any running children if an earlier child returns false or true, respectively.

It does not implement halting for parallel nodes or async/remote action nodes.

This PR is part of #65

@samouwow samouwow changed the title Add halt for flow and decorator nodes. Add halt for flow, decorator and sync action nodes. Jun 26, 2024
@besok
Copy link
Collaborator

besok commented Jun 26, 2024

Great work! Thanks for the PR. I will take a look on friday!

Copy link
Collaborator

@besok besok left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good to me... a couple of small comments though

let running_child_cursor = tick_args
.find(RUNNING_CHILD.to_string())
.and_then(RtValue::as_int)
.and_then(|v| Some(v as usize));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.and_then(|v| Some(v as usize)) better to replace to .map(|v| v as usize)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense, fixed.

@@ -299,6 +365,10 @@ pub fn monitor(
pub enum FlowDecision {
PopNode(RNodeState),
Stay(RNodeState),
Halt {
new_state: RNodeState,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since it is an internal class that i used here I would suggest to

type HaltingChildCursor = i64;
Halt(RNodeState,HaltingChildCursor), 

or simply

Halt(RNodeState,i64), 

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough, that's reasonable.

I really like the self-documenting nature of explicitly labelling the second element as the cursor for the halting child, so I'm going to go for your first suggest. I'm worried just i64 will be harder to understand and maintain going forwards.

The code has been updated.

match flow::monitor(tpe, args.clone(), tick_args, &mut ctx)? {
match flow::monitor(
tpe,
init_args.clone(),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can i suggest returning the formatting?

match flow::monitor(tpe, init_args.clone(), tick_args, &mut ctx)? {

Copy link
Contributor Author

@samouwow samouwow Jun 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's just how cargo fmt / rust-analyzer auto-formats it. Does your cargo fmt format it differently?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It did not break it into several lines but apparently, I was not using cargo fmt but rather default ide (rustrover) formater. Yeah, keep it as is then

@@ -225,17 +230,26 @@ impl Forester {
debug!(target:"flow[run]", "tick:{}, {tpe}. stay with the new state: {}",ctx.curr_ts(),&ns);
ctx.new_state(id, ns)?;
}
FlowDecision::Halt { .. } => {
unreachable!("A child returning running should not trigger a flow node halt decision.");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe better to return an error immediately here?

return Err(RuntimeError::Unexpected("A child returning running should not trigger a flow node halt decision."))

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good suggestion, fixed.

// Halting must be an atomic process, it is never spread over multiple ticks so should never be seen in this flow.
RNodeState::Halting(_) => {
unreachable!(
"A flow node child should never return a state of Halting."
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe better to return an error immediately here?

return Err(RuntimeError::Unexpected("A child returning running should not trigger a flow node halt decision."))

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good suggestion, fixed.

// Halting must be an atomic process, it is never spread over multiple ticks so should never be seen in this flow.
RNodeState::Halting(_) => {
unreachable!(
"A decorator node child should never return a state of Halting."
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and here - return instead of panic?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good suggestion, fixed.

@besok
Copy link
Collaborator

besok commented Jun 27, 2024

Thank you for the great PR. The idea is very nice.
I have left a couple of notes but apart of that it looks good to me.

@samouwow
Copy link
Contributor Author

Thanks for the quick review.

I've implemented all your suggestions except the formatting one, since I'd rather just keep letting cargo fmt do its thing.

@besok besok merged commit 6fac087 into forester-bt:main Jun 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants