simln-lib/feature: Add ability to run with mocked ln network #248
Conversation
f3r10
force-pushed
the
feature_add_ability_to_run_with_mocked_ln_network
branch
from
6795897 to
3d2685b
Compare
|
Is this ready for a first review pass? |
|
Sure, @carlaKC, it is ready for a first review pass. I have been thinking about how to add some tests |
f3r10
force-pushed
the
feature_add_ability_to_run_with_mocked_ln_network
branch
from
3d2685b to
140f087
Compare
There was a problem hiding this comment.
A few big picture comments on how we're going to split this up, now that I've had some time to think about this (and live with these decisions on a downstream fork) I think we can cut it up a bit cleaner.
Also feel free to cherry pick carlaKC@d1afc33 for docs once this reaches the stage where you need then (removing the embarrassing rebase booger in there, kek).
| @@ -96,6 +101,27 @@ enum NodeConnection { | |||
| Eclair(eclair::EclairConnection), | |||
| } | |||
|
|
|||
| /// Data structure that is used to parse information from the simulation file, used to pair two node policies together | |||
| /// without the other internal state that is used in our simulated network. | |||
There was a problem hiding this comment.
wdym by "without the other internal state that is used in our simulated network?"
Without all the stuff in SimulatedChannel? I don't think the parsing module needs to worry too much about noting that - we have a few structs across modules that are quite duplicated but different for the sake of separation.
| @@ -20,7 +20,7 @@ async fn main() -> anyhow::Result<()> { | |||
| .init() | |||
| .unwrap(); | |||
|
|
|||
| let sim = create_simulation(&cli).await?; | |||
| let (sim, sim_network) = create_simulation(&cli).await?; | |||
There was a problem hiding this comment.
I'm torn about whether to have all the logic about our two different run "modes" here vs hidden in create_simulation (I know I did that in my branch, but I didn't love it).
WDYT of something like this which separates validation and has two dedicated functions that assumes we've done some validation on cli:
cli.validate()?; // does all the checks on nodes and sim_network
let tasks = TaskTracker::new();
let sim = if sim.network.is_none() {
create_simulation(cli, tasks)
} else {
create_simulation_with_network(cli, tasks);
}
sim.run()
tasks.wait
I don't like that we have some duplication in the different create network functions, but it is nice to clearly see the two cases and have more specialized functions.
(Related to comment about getting rid of new_with_sim_network)
There was a problem hiding this comment.
I agree; it makes the code more concise
| @@ -654,7 +655,7 @@ pub struct SimGraph { | |||
|
|
|||
| /// track all tasks spawned to process payments in the graph. Note that handling the shutdown of tasks | |||
| /// in this tracker must be done externally. | |||
| tasks: TaskTracker, | |||
| pub tasks: TaskTracker, | |||
There was a problem hiding this comment.
If we're passing tasks into the constructor, we should have it available at our call site and then don't need to make it pub?
| @@ -527,6 +528,42 @@ impl Simulation { | |||
| } | |||
| } | |||
|
|
|||
| pub async fn new_with_sim_network( | |||
There was a problem hiding this comment.
On second look, this seems like a bit of a layering violation to have Simulation be aware of SimGraph stuff - it should just care about getting some arbitrary set of lightning nodes.
If we have a dedicated create_simulation_with_network in the parsing module, we can just create the graph with SimGraph::new and then use ln_node_from_graph to get the nodes to pass into Simulation::new.
The nice side effect of passing tasks in is that we don't actually need the graph to wait on anymore, we can just tasks.wait at the end of the sim.
address #215