Skip to content

Report Pathfinding Outcomes to Scorer in SimNode #291

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

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

chuksys
Copy link
Contributor

@chuksys chuksys commented Jun 25, 2025

Description

This PR reports pathfinding outcomes to scorer in SimNode. This significantly improves the realism of pathfinding simulations by allowing the scorer to update based on actual payment success or failure.

This is an attempt to complete the work started on this branch.

Changes

  • Payment path now tracked in SimNode.in_flight using InFlightPayment.
  • Added IndexFailure PaymentOutcome variant, which specifically captures the index of the channel in the payment path that caused the failure.
  • Now tracking simulation time in SimNode using SimulationClock for accurate duration reporting.
  • Now reporting payment success/failure to SimNode.scorer using the newly tracked path and failure index (if applicable).

This PR closes #279

@chuksys chuksys force-pushed the report-pathfinding-outcomes branch 3 times, most recently from d151ed3 to 32c4089 Compare June 25, 2025 17:41
@carlaKC
Copy link
Contributor

carlaKC commented Jun 26, 2025

Looking really good overall!

Let's sort out these pesky MPP issues and make the clock generic then we're gg.

@chuksys
Copy link
Contributor Author

chuksys commented Jun 27, 2025

Thanks for the feedback. Will get this sorted asap!

@chuksys
Copy link
Contributor Author

chuksys commented Jul 7, 2025

Added Some Key Changes

  1. Reverted SimNode Immutability: I've reverted some changes introduced in 8ded28e to allow SimNode to mutate its internal fields where necessary.

  2. Added Test Cases for First Hop Failure: New test cases have been added to specifically verify that when a Some(0) is returned during the simulation's payment propagation, it correctly indicates a failure on the first hop (Index 0).

Copy link
Contributor

@carlaKC carlaKC left a comment

Choose a reason for hiding this comment

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

Some questions from a very high level pass.

Reverted SimNode Immutability: I've reverted some changes introduced in 8ded28e to allow SimNode to mutate its internal fields where necessary.

What's the motivation for reverting this change? If possible it's preferable to not require implementations of a trait to be mutable. Would rather add a mutex where we need it than re-introduce trait-required mutability.

@@ -1067,6 +1058,7 @@ pub async fn ln_node_from_graph(
node.1 .0.clone(),
graph.clone(),
routing_graph.clone(),
SystemClock {}
Copy link
Contributor

Choose a reason for hiding this comment

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

We should pass this clock in as a parameter to give callers the freedom to choose what impl they want

@@ -1211,6 +1216,77 @@ impl SimNetwork for SimGraph {
}
}

/// This trait defines the "interface" for payment propagation logic
pub trait PaymentPropagator: Send + Sync + 'static {
Copy link
Contributor

Choose a reason for hiding this comment

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

This seems like a lot of boilerplate just for tests (and possibly somewhere we should use async_trait rather than have these boxes + pins?

Doesn't seem like it would be too much test code to just use real propagation and create payments that fail at the points we want?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, you are right - I actually used async_trait in a fixup of the commit; However I think it's a good idea to use real propagation rather than have all this boilerplate. I'll work on that.

@chuksys
Copy link
Contributor Author

chuksys commented Jul 8, 2025

Would rather add a mutex where we need it than re-introduce trait-required mutability.

Thanks for this suggestion. Will work on this.

@chuksys chuksys requested a review from carlaKC July 9, 2025 00:46
Copy link
Contributor

@carlaKC carlaKC left a comment

Choose a reason for hiding this comment

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

I think that you can go ahead and squash this then I'll take a last review round.

Just a few generics things that stand out to me.

@@ -313,7 +313,7 @@ pub async fn create_simulation_with_network(
// custom actions on the simulated network. For the nodes we'll pass our simulation, cast them
// to a dyn trait and exclude any nodes that shouldn't be included in random activity
// generation.
let nodes = ln_node_from_graph(simulation_graph.clone(), routing_graph).await;
let nodes = ln_node_from_graph(simulation_graph.clone(), routing_graph, SystemClock {}).await?;
Copy link
Contributor

Choose a reason for hiding this comment

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

Should use the clock passed in?

@@ -12,7 +12,7 @@ pub trait Clock: Send + Sync {
}

/// Provides a wall clock implementation of the Clock trait.
#[derive(Clone)]
#[derive(Clone, Copy)]
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need to add Copy?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We actually don't need to - will take that out.

@@ -1019,11 +1061,12 @@ impl SimGraph {
}

/// Produces a map of node public key to lightning node implementation to be used for simulations.
pub async fn ln_node_from_graph(
pub async fn ln_node_from_graph<C: Clock + std::marker::Copy>(
Copy link
Contributor

Choose a reason for hiding this comment

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

Rather than require this to be copy, pass in Arc<C>? This is what we do elsewhere

elnosh and others added 7 commits July 11, 2025 19:08
This commit ensures that the payment apis can only send to a single path.

Payment is rejected if the route has multiple paths.
This commit asserts that payment failure on first hop returns Some(0).

On payment failure, this ensures the correct index of hop where failure occured is reported to scorer.
@chuksys chuksys force-pushed the report-pathfinding-outcomes branch from 2eeda7a to 3dfc98a Compare July 13, 2025 17:28
@chuksys chuksys requested a review from carlaKC July 14, 2025 08:10
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.

Feature Request: Report pathfinding outcomes to scorer in SimNode
3 participants