Skip to content

Conversation

@matheus23
Copy link
Member

@matheus23 matheus23 commented Nov 18, 2025

Intended for merging into #3676

  • Makes idle_timeout always be a time::Sleep that is .reset once there is any activity. I find this much easier to reason about.
  • Fixes a bug where handle_msg_send_datagram short-circuits when sending on one path fails. Instead, it should try all paths, even if some of them fail.

@matheus23 matheus23 requested a review from Frando November 18, 2025 13:34
@matheus23 matheus23 self-assigned this Nov 18, 2025
@github-actions
Copy link

github-actions bot commented Nov 18, 2025

Documentation for this PR has been generated and is available at: https://n0-computer.github.io/iroh/pr/3678/docs/iroh/

Last updated: 2025-11-18T17:19:44Z

@matheus23 matheus23 force-pushed the matheus23/mp-discovery branch from 43d6cc7 to 065f81d Compare November 18, 2025 13:55
@matheus23 matheus23 changed the base branch from Frando/mp-discovery to Frando/mp-fix-remote-state-actor-loop November 18, 2025 13:55
let idle_timeout = MaybeFuture::None;
tokio::pin!(idle_timeout);
let idle_timeout = time::sleep(ACTOR_MAX_IDLE_TIMEOUT);
n0_future::pin!(idle_timeout);
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Member Author

Choose a reason for hiding this comment

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

Fair. I wanted to match the rest of the code's style.

Copy link
Member Author

Choose a reason for hiding this comment

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

Err.. Seems like that macro actually does something different. It doesn't seem to be a drop-in replacement for neither tokio::pin! nor n0_future::pin! in this situation.

Copy link
Contributor

Choose a reason for hiding this comment

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

let mut idle_timeout = std::pin::pin!(time::sleep(...)) is the std version. I don't really know which I prefer, this version existed in n0_future so I assumed we liked it for some reason?

@n0bot n0bot bot added this to iroh Nov 18, 2025
@github-project-automation github-project-automation bot moved this to 🏗 In progress in iroh Nov 18, 2025
@matheus23 matheus23 changed the title Simplify the idle timeout logic Simplify the idle timeout logic & don't short-circuit in handle_msg_send_datagram Nov 18, 2025
@github-actions
Copy link

github-actions bot commented Nov 18, 2025

Netsim report & logs for this PR have been generated and is available at: LOGS
This report will remain available for 3 days.

Last updated for commit: 0481183

Copy link
Contributor

@flub flub left a comment

Choose a reason for hiding this comment

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

I prefer this version too.

@matheus23
Copy link
Member Author

Not sure why netsim fails now :/ I've tried to spelunking in the logs, but couldn't find anything easily. I thought we'd fixed all netsim issues in this stack of PRs. :/ TBD.

@Frando
Copy link
Member

Frando commented Nov 18, 2025

Weird, it seems to complete successfully yet the logs say the process completed with error code 1. @Arqu any ideas?
IMG_20251118_211033.jpg

@matheus23
Copy link
Member Author

This log seems to come from chuck's util.py file, IIUC. And it seems like it defaults to exit code 1, if no exit code is provided?
Looking at the conditions when this function is called, it seems like it's called in eject, which is only called in main.py when monitor_short_processes returns any process errors, which can basically happen if the process returns a non-0 exit code or times out. However, these errors are printed, but I can't find a single "Process timeout" or "Process failed" in any log file. And as far as I can tell, there's no other place that eject, and thus transitively, logs_on_error are called.

help

@matheus23 matheus23 merged commit 899df00 into Frando/mp-fix-remote-state-actor-loop Nov 20, 2025
50 of 53 checks passed
@github-project-automation github-project-automation bot moved this from 🏗 In progress to ✅ Done in iroh Nov 20, 2025
@matheus23 matheus23 deleted the matheus23/mp-discovery branch November 20, 2025 08:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: ✅ Done

Development

Successfully merging this pull request may close these issues.

5 participants