Payment benchmark by joostjager · Pull Request #664 · lightningdevkit/ldk-node

joostjager · 2025-10-15T08:47:30Z

This PR adds a new async payment benchmark test to integration_tests_rust.rs. The test sets up two nodes with a channel and measures performance while sending 1,000 concurrent payments. It uses Tokio’s multi-threaded runtime to spawn payments as separate async tasks and tracks completion through LDK events. The benchmark provides a simple way to gauge throughput and identify performance bottlenecks in payment handling.

Related: lightningdevkit/rust-lightning#4161

ldk-reviews-bot · 2025-10-15T08:47:33Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

joostjager · 2025-10-21T13:04:00Z

Converted test to criterion benchmark and added it to CI. Also removed the payment throttling, now that it has been established that there is a bug in lightning-net-tokio that causes this. For the benchmark, the 1000 payments can now simply be launched at the same time.

Criterion reports outliers, so this should be able to detect to occassional 30 sec hangs in the payments test.

ldk-reviews-bot · 2025-10-23T13:04:43Z

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-10-25T13:05:28Z

🔔 2nd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-10-27T13:06:14Z

🔔 3rd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

joostjager · 2025-10-28T10:37:23Z

Rebased onto async test framework changes.

tnull · 2025-10-28T13:07:22Z

Mind rebasing once more to fix CI?

tnull

Thanks! The test store changes don't make sense to me, I believe you intended something else there. Otherwise some comments.

tnull · 2025-10-28T13:10:00Z

-	let node = builder.build_with_store(test_sync_store).unwrap();
+	let kv_store: Arc<DynStore> = match config.store_type {
+ TestStoreType::InMemory => {
+ Arc::new(TestSyncStore::new(config.node_config.storage_dir_path.into()))


This doesn't do what you think it does. This is TestSyncStore, a store that writes to multiple backends to ensure they are kept in-sync, not the in-memory TestStore.

Ah, I missed that indeed. Renamed InMemory to TestSyncStore. The intention of the commit is to allow a test/benchmark to run with sqlite (only).

tnull · 2025-10-28T13:21:06Z

+
+	// Spawn each payment as a separate async task
+	task::spawn(async move {
+ println!("{}: Starting payment", payment_hash.0.as_hex());


Are we positive all the printing IO doesn't impact the performance? Should we omit this for 'production' benchmarking?

I did wonder the same. Maybe I should indeed remove it to be sure. Would that be a cfg flag?

Could be, but do we really need them in the first place?

tnull · 2025-10-28T13:24:15Z

+ // Pre-check the HTLC slots to try to avoid the performance impact of a failed payment.
+ while node_a.list_channels()[0].next_outbound_htlc_limit_msat == 0 {
+ println!("{}: Waiting for HTLC slots to free up", payment_hash.0.as_hex());
+ tokio::time::sleep(std::time::Duration::from_millis(100)).await;


How did you determine 100ms here? Do we have an intuition if this could starve any of the waiting payers?

It isn't great indeed. Basically something that looked 'reasonable' to me. I think it is a weakness in the API that a user even needs to do this.

tnull · 2025-10-29T09:48:19Z

+ Arc::new(TestSyncStore::new(config.node_config.storage_dir_path.into()))
+ },
+ TestStoreType::Sqlite => Arc::new(
+ SqliteStore::new(


Let's just use the default build() here, which defaults to SQLite.
If you prefer to have it explicit, feel free to rename build to build_with_sqlite_store and have a new build method on Builder call it. Then you can explicitly set build_with_sqlite_store here.

No, it's alright to use build. Done.

tnull · 2025-10-29T09:50:31Z

+ // Pre-check the HTLC slots to try to avoid the performance impact of a failed payment.
+ while node_a.list_channels()[0].next_outbound_htlc_limit_msat == 0 {
+ println!("{}: Waiting for HTLC slots to free up", payment_hash.0.as_hex());
+ tokio::time::sleep(std::time::Duration::from_millis(100)).await;


tnull · 2025-10-29T09:51:00Z


 vss-client = "0.3"
 prost = { version = "0.11.6", default-features = false}
+criterion = { version = "0.7.0", features = ["async_tokio"] }


Why is this not a dev-dependency?

tnull

Feel free to squash fixups. CI is currently broken with warnings and errors:

warning: unused imports: `KV_TABLE_NAME` and `SQLITE_DB_FILE_NAME`
--> tests/common/mod.rs:32:47
|
32 | use ldk_node::io::sqlite_store::{SqliteStore, KV_TABLE_NAME, SQLITE_DB_FILE_NAME};
| ^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^
|
= note: `#[warn(unused_imports)]` on by default
warning: unused import: `DynStore`
--> tests/common/mod.rs:35:28
|
35 | Builder, CustomTlvRecord, DynStore, Event, LightningBalance, Node, NodeError,
| ^^^^^^^^
error[E0308]: arguments to this function are incorrect
--> tests/benchmarks.rs:185:15
|
185 | total += send_payments(node_a, node_b).await;
| ^^^^^^^^^^^^^
|
note: expected `Arc<Node>`, found `Arc<Arc<Node>>`
--> tests/benchmarks.rs:185:29
|
185 | total += send_payments(node_a, node_b).await;
| ^^^^^^
= note: expected struct `Arc<ldk_node::Node>`
found struct `Arc<Arc<ldk_node::Node>>`
note: expected `Arc<Node>`, found `Arc<Arc<Node>>`
--> tests/benchmarks.rs:185:37
|
185 | total += send_payments(node_a, node_b).await;
| ^^^^^^
= note: expected struct `Arc<ldk_node::Node>`
found struct `Arc<Arc<ldk_node::Node>>`
note: function defined here
--> tests/benchmarks.rs:63:10
|
63 | async fn send_payments(node_a: Arc<Node>, node_b: Arc<Node>) -> std::time::Duration {
| ^^^^^^^^^^^^^ ----------------- -----------------

To enable more realistic testing with sqlite as a backend.

joostjager · 2025-10-31T15:20:30Z

Had to move the code to the standard benches folder, which is better anyway.

tnull

LGTM, please squash.

Introduces a criterion-based benchmark that sends 1000 concurrent payments between two LDK nodes to measure total duration. Also adds a CI job to automatically run the benchmark.

joostjager · 2025-10-15T08:47:30Z

This PR adds a new async payment benchmark test to integration_tests_rust.rs. The test sets up two nodes with a channel and measures performance while sending 1,000 concurrent payments. It uses Tokio’s multi-threaded runtime to spawn payments as separate async tasks and tracks completion through LDK events. The benchmark provides a simple way to gauge throughput and identify performance bottlenecks in payment handling.

Related: lightningdevkit/rust-lightning#4161

ldk-reviews-bot · 2025-10-15T08:47:33Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

joostjager · 2025-10-21T13:04:00Z

Converted test to criterion benchmark and added it to CI. Also removed the payment throttling, now that it has been established that there is a bug in lightning-net-tokio that causes this. For the benchmark, the 1000 payments can now simply be launched at the same time.

Criterion reports outliers, so this should be able to detect to occassional 30 sec hangs in the payments test.

ldk-reviews-bot · 2025-10-23T13:04:43Z

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-10-25T13:05:28Z

🔔 2nd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-10-27T13:06:14Z

🔔 3rd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

joostjager · 2025-10-28T10:37:23Z

Rebased onto async test framework changes.

tnull · 2025-10-28T13:07:22Z

Mind rebasing once more to fix CI?

tnull

Thanks! The test store changes don't make sense to me, I believe you intended something else there. Otherwise some comments.

tnull · 2025-10-28T13:10:00Z

-	let node = builder.build_with_store(test_sync_store).unwrap();
+	let kv_store: Arc<DynStore> = match config.store_type {
+ TestStoreType::InMemory => {
+ Arc::new(TestSyncStore::new(config.node_config.storage_dir_path.into()))


This doesn't do what you think it does. This is TestSyncStore, a store that writes to multiple backends to ensure they are kept in-sync, not the in-memory TestStore.

Ah, I missed that indeed. Renamed InMemory to TestSyncStore. The intention of the commit is to allow a test/benchmark to run with sqlite (only).

tnull · 2025-10-28T13:21:06Z

+
+	// Spawn each payment as a separate async task
+	task::spawn(async move {
+ println!("{}: Starting payment", payment_hash.0.as_hex());


Are we positive all the printing IO doesn't impact the performance? Should we omit this for 'production' benchmarking?

I did wonder the same. Maybe I should indeed remove it to be sure. Would that be a cfg flag?

Could be, but do we really need them in the first place?

tnull · 2025-10-28T13:24:15Z

+ // Pre-check the HTLC slots to try to avoid the performance impact of a failed payment.
+ while node_a.list_channels()[0].next_outbound_htlc_limit_msat == 0 {
+ println!("{}: Waiting for HTLC slots to free up", payment_hash.0.as_hex());
+ tokio::time::sleep(std::time::Duration::from_millis(100)).await;


How did you determine 100ms here? Do we have an intuition if this could starve any of the waiting payers?

It isn't great indeed. Basically something that looked 'reasonable' to me. I think it is a weakness in the API that a user even needs to do this.

tnull · 2025-10-29T09:48:19Z

+ Arc::new(TestSyncStore::new(config.node_config.storage_dir_path.into()))
+ },
+ TestStoreType::Sqlite => Arc::new(
+ SqliteStore::new(


Let's just use the default build() here, which defaults to SQLite.
If you prefer to have it explicit, feel free to rename build to build_with_sqlite_store and have a new build method on Builder call it. Then you can explicitly set build_with_sqlite_store here.

No, it's alright to use build. Done.

tnull · 2025-10-29T09:50:31Z

+ // Pre-check the HTLC slots to try to avoid the performance impact of a failed payment.
+ while node_a.list_channels()[0].next_outbound_htlc_limit_msat == 0 {
+ println!("{}: Waiting for HTLC slots to free up", payment_hash.0.as_hex());
+ tokio::time::sleep(std::time::Duration::from_millis(100)).await;


tnull · 2025-10-29T09:51:00Z


 vss-client = "0.3"
 prost = { version = "0.11.6", default-features = false}
+criterion = { version = "0.7.0", features = ["async_tokio"] }


Why is this not a dev-dependency?

tnull

Feel free to squash fixups. CI is currently broken with warnings and errors:

warning: unused imports: `KV_TABLE_NAME` and `SQLITE_DB_FILE_NAME`
--> tests/common/mod.rs:32:47
|
32 | use ldk_node::io::sqlite_store::{SqliteStore, KV_TABLE_NAME, SQLITE_DB_FILE_NAME};
| ^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^
|
= note: `#[warn(unused_imports)]` on by default
warning: unused import: `DynStore`
--> tests/common/mod.rs:35:28
|
35 | Builder, CustomTlvRecord, DynStore, Event, LightningBalance, Node, NodeError,
| ^^^^^^^^
error[E0308]: arguments to this function are incorrect
--> tests/benchmarks.rs:185:15
|
185 | total += send_payments(node_a, node_b).await;
| ^^^^^^^^^^^^^
|
note: expected `Arc<Node>`, found `Arc<Arc<Node>>`
--> tests/benchmarks.rs:185:29
|
185 | total += send_payments(node_a, node_b).await;
| ^^^^^^
= note: expected struct `Arc<ldk_node::Node>`
found struct `Arc<Arc<ldk_node::Node>>`
note: expected `Arc<Node>`, found `Arc<Arc<Node>>`
--> tests/benchmarks.rs:185:37
|
185 | total += send_payments(node_a, node_b).await;
| ^^^^^^
= note: expected struct `Arc<ldk_node::Node>`
found struct `Arc<Arc<ldk_node::Node>>`
note: function defined here
--> tests/benchmarks.rs:63:10
|
63 | async fn send_payments(node_a: Arc<Node>, node_b: Arc<Node>) -> std::time::Duration {
| ^^^^^^^^^^^^^ ----------------- -----------------

To enable more realistic testing with sqlite as a backend.

joostjager · 2025-10-31T15:20:30Z

Had to move the code to the standard benches folder, which is better anyway.

tnull

LGTM, please squash.

Introduces a criterion-based benchmark that sends 1000 concurrent payments between two LDK nodes to measure total duration. Also adds a CI job to automatically run the benchmark.

joostjager · 2025-10-15T08:47:30Z

This PR adds a new async payment benchmark test to integration_tests_rust.rs. The test sets up two nodes with a channel and measures performance while sending 1,000 concurrent payments. It uses Tokio’s multi-threaded runtime to spawn payments as separate async tasks and tracks completion through LDK events. The benchmark provides a simple way to gauge throughput and identify performance bottlenecks in payment handling.

Related: lightningdevkit/rust-lightning#4161

ldk-reviews-bot · 2025-10-15T08:47:33Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

joostjager · 2025-10-21T13:04:00Z

Converted test to criterion benchmark and added it to CI. Also removed the payment throttling, now that it has been established that there is a bug in lightning-net-tokio that causes this. For the benchmark, the 1000 payments can now simply be launched at the same time.

Criterion reports outliers, so this should be able to detect to occassional 30 sec hangs in the payments test.

ldk-reviews-bot · 2025-10-23T13:04:43Z

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-10-25T13:05:28Z

🔔 2nd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-10-27T13:06:14Z

🔔 3rd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

joostjager · 2025-10-28T10:37:23Z

Rebased onto async test framework changes.

tnull · 2025-10-28T13:07:22Z

Mind rebasing once more to fix CI?

tnull

Thanks! The test store changes don't make sense to me, I believe you intended something else there. Otherwise some comments.

tnull · 2025-10-28T13:10:00Z

-	let node = builder.build_with_store(test_sync_store).unwrap();
+	let kv_store: Arc<DynStore> = match config.store_type {
+ TestStoreType::InMemory => {
+ Arc::new(TestSyncStore::new(config.node_config.storage_dir_path.into()))


This doesn't do what you think it does. This is TestSyncStore, a store that writes to multiple backends to ensure they are kept in-sync, not the in-memory TestStore.

Ah, I missed that indeed. Renamed InMemory to TestSyncStore. The intention of the commit is to allow a test/benchmark to run with sqlite (only).

tnull · 2025-10-28T13:21:06Z

+
+	// Spawn each payment as a separate async task
+	task::spawn(async move {
+ println!("{}: Starting payment", payment_hash.0.as_hex());


Are we positive all the printing IO doesn't impact the performance? Should we omit this for 'production' benchmarking?

I did wonder the same. Maybe I should indeed remove it to be sure. Would that be a cfg flag?

Could be, but do we really need them in the first place?

tnull · 2025-10-28T13:24:15Z

+ // Pre-check the HTLC slots to try to avoid the performance impact of a failed payment.
+ while node_a.list_channels()[0].next_outbound_htlc_limit_msat == 0 {
+ println!("{}: Waiting for HTLC slots to free up", payment_hash.0.as_hex());
+ tokio::time::sleep(std::time::Duration::from_millis(100)).await;


How did you determine 100ms here? Do we have an intuition if this could starve any of the waiting payers?

It isn't great indeed. Basically something that looked 'reasonable' to me. I think it is a weakness in the API that a user even needs to do this.

tnull · 2025-10-29T09:48:19Z

+ Arc::new(TestSyncStore::new(config.node_config.storage_dir_path.into()))
+ },
+ TestStoreType::Sqlite => Arc::new(
+ SqliteStore::new(


Let's just use the default build() here, which defaults to SQLite.
If you prefer to have it explicit, feel free to rename build to build_with_sqlite_store and have a new build method on Builder call it. Then you can explicitly set build_with_sqlite_store here.

No, it's alright to use build. Done.

tnull · 2025-10-29T09:50:31Z

+ // Pre-check the HTLC slots to try to avoid the performance impact of a failed payment.
+ while node_a.list_channels()[0].next_outbound_htlc_limit_msat == 0 {
+ println!("{}: Waiting for HTLC slots to free up", payment_hash.0.as_hex());
+ tokio::time::sleep(std::time::Duration::from_millis(100)).await;


tnull · 2025-10-29T09:51:00Z


 vss-client = "0.3"
 prost = { version = "0.11.6", default-features = false}
+criterion = { version = "0.7.0", features = ["async_tokio"] }


Why is this not a dev-dependency?

tnull

Feel free to squash fixups. CI is currently broken with warnings and errors:

warning: unused imports: `KV_TABLE_NAME` and `SQLITE_DB_FILE_NAME`
--> tests/common/mod.rs:32:47
|
32 | use ldk_node::io::sqlite_store::{SqliteStore, KV_TABLE_NAME, SQLITE_DB_FILE_NAME};
| ^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^
|
= note: `#[warn(unused_imports)]` on by default
warning: unused import: `DynStore`
--> tests/common/mod.rs:35:28
|
35 | Builder, CustomTlvRecord, DynStore, Event, LightningBalance, Node, NodeError,
| ^^^^^^^^
error[E0308]: arguments to this function are incorrect
--> tests/benchmarks.rs:185:15
|
185 | total += send_payments(node_a, node_b).await;
| ^^^^^^^^^^^^^
|
note: expected `Arc<Node>`, found `Arc<Arc<Node>>`
--> tests/benchmarks.rs:185:29
|
185 | total += send_payments(node_a, node_b).await;
| ^^^^^^
= note: expected struct `Arc<ldk_node::Node>`
found struct `Arc<Arc<ldk_node::Node>>`
note: expected `Arc<Node>`, found `Arc<Arc<Node>>`
--> tests/benchmarks.rs:185:37
|
185 | total += send_payments(node_a, node_b).await;
| ^^^^^^
= note: expected struct `Arc<ldk_node::Node>`
found struct `Arc<Arc<ldk_node::Node>>`
note: function defined here
--> tests/benchmarks.rs:63:10
|
63 | async fn send_payments(node_a: Arc<Node>, node_b: Arc<Node>) -> std::time::Duration {
| ^^^^^^^^^^^^^ ----------------- -----------------

To enable more realistic testing with sqlite as a backend.

joostjager · 2025-10-31T15:20:30Z

Had to move the code to the standard benches folder, which is better anyway.

tnull

LGTM, please squash.

Introduces a criterion-based benchmark that sends 1000 concurrent payments between two LDK nodes to measure total duration. Also adds a CI job to automatically run the benchmark.

joostjager · 2025-10-15T08:47:30Z

This PR adds a new async payment benchmark test to integration_tests_rust.rs. The test sets up two nodes with a channel and measures performance while sending 1,000 concurrent payments. It uses Tokio’s multi-threaded runtime to spawn payments as separate async tasks and tracks completion through LDK events. The benchmark provides a simple way to gauge throughput and identify performance bottlenecks in payment handling.

Related: lightningdevkit/rust-lightning#4161

ldk-reviews-bot · 2025-10-15T08:47:33Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

joostjager · 2025-10-21T13:04:00Z

Converted test to criterion benchmark and added it to CI. Also removed the payment throttling, now that it has been established that there is a bug in lightning-net-tokio that causes this. For the benchmark, the 1000 payments can now simply be launched at the same time.

Criterion reports outliers, so this should be able to detect to occassional 30 sec hangs in the payments test.

ldk-reviews-bot · 2025-10-23T13:04:43Z

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-10-25T13:05:28Z

🔔 2nd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-10-27T13:06:14Z

🔔 3rd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

joostjager · 2025-10-28T10:37:23Z

Rebased onto async test framework changes.

tnull · 2025-10-28T13:07:22Z

Mind rebasing once more to fix CI?

tnull

Thanks! The test store changes don't make sense to me, I believe you intended something else there. Otherwise some comments.

tnull · 2025-10-28T13:10:00Z

-	let node = builder.build_with_store(test_sync_store).unwrap();
+	let kv_store: Arc<DynStore> = match config.store_type {
+ TestStoreType::InMemory => {
+ Arc::new(TestSyncStore::new(config.node_config.storage_dir_path.into()))


This doesn't do what you think it does. This is TestSyncStore, a store that writes to multiple backends to ensure they are kept in-sync, not the in-memory TestStore.

Ah, I missed that indeed. Renamed InMemory to TestSyncStore. The intention of the commit is to allow a test/benchmark to run with sqlite (only).

tnull · 2025-10-28T13:21:06Z

+
+	// Spawn each payment as a separate async task
+	task::spawn(async move {
+ println!("{}: Starting payment", payment_hash.0.as_hex());


Are we positive all the printing IO doesn't impact the performance? Should we omit this for 'production' benchmarking?

I did wonder the same. Maybe I should indeed remove it to be sure. Would that be a cfg flag?

Could be, but do we really need them in the first place?

tnull · 2025-10-28T13:24:15Z

+ // Pre-check the HTLC slots to try to avoid the performance impact of a failed payment.
+ while node_a.list_channels()[0].next_outbound_htlc_limit_msat == 0 {
+ println!("{}: Waiting for HTLC slots to free up", payment_hash.0.as_hex());
+ tokio::time::sleep(std::time::Duration::from_millis(100)).await;


How did you determine 100ms here? Do we have an intuition if this could starve any of the waiting payers?

It isn't great indeed. Basically something that looked 'reasonable' to me. I think it is a weakness in the API that a user even needs to do this.

tnull · 2025-10-29T09:48:19Z

+ Arc::new(TestSyncStore::new(config.node_config.storage_dir_path.into()))
+ },
+ TestStoreType::Sqlite => Arc::new(
+ SqliteStore::new(


Let's just use the default build() here, which defaults to SQLite.
If you prefer to have it explicit, feel free to rename build to build_with_sqlite_store and have a new build method on Builder call it. Then you can explicitly set build_with_sqlite_store here.

No, it's alright to use build. Done.

tnull · 2025-10-29T09:50:31Z

+ // Pre-check the HTLC slots to try to avoid the performance impact of a failed payment.
+ while node_a.list_channels()[0].next_outbound_htlc_limit_msat == 0 {
+ println!("{}: Waiting for HTLC slots to free up", payment_hash.0.as_hex());
+ tokio::time::sleep(std::time::Duration::from_millis(100)).await;


tnull · 2025-10-29T09:51:00Z


 vss-client = "0.3"
 prost = { version = "0.11.6", default-features = false}
+criterion = { version = "0.7.0", features = ["async_tokio"] }


Why is this not a dev-dependency?

tnull

Feel free to squash fixups. CI is currently broken with warnings and errors:

warning: unused imports: `KV_TABLE_NAME` and `SQLITE_DB_FILE_NAME`
--> tests/common/mod.rs:32:47
|
32 | use ldk_node::io::sqlite_store::{SqliteStore, KV_TABLE_NAME, SQLITE_DB_FILE_NAME};
| ^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^
|
= note: `#[warn(unused_imports)]` on by default
warning: unused import: `DynStore`
--> tests/common/mod.rs:35:28
|
35 | Builder, CustomTlvRecord, DynStore, Event, LightningBalance, Node, NodeError,
| ^^^^^^^^
error[E0308]: arguments to this function are incorrect
--> tests/benchmarks.rs:185:15
|
185 | total += send_payments(node_a, node_b).await;
| ^^^^^^^^^^^^^
|
note: expected `Arc<Node>`, found `Arc<Arc<Node>>`
--> tests/benchmarks.rs:185:29
|
185 | total += send_payments(node_a, node_b).await;
| ^^^^^^
= note: expected struct `Arc<ldk_node::Node>`
found struct `Arc<Arc<ldk_node::Node>>`
note: expected `Arc<Node>`, found `Arc<Arc<Node>>`
--> tests/benchmarks.rs:185:37
|
185 | total += send_payments(node_a, node_b).await;
| ^^^^^^
= note: expected struct `Arc<ldk_node::Node>`
found struct `Arc<Arc<ldk_node::Node>>`
note: function defined here
--> tests/benchmarks.rs:63:10
|
63 | async fn send_payments(node_a: Arc<Node>, node_b: Arc<Node>) -> std::time::Duration {
| ^^^^^^^^^^^^^ ----------------- -----------------

To enable more realistic testing with sqlite as a backend.

joostjager · 2025-10-31T15:20:30Z

Had to move the code to the standard benches folder, which is better anyway.

tnull

LGTM, please squash.

Introduces a criterion-based benchmark that sends 1000 concurrent payments between two LDK nodes to measure total duration. Also adds a CI job to automatically run the benchmark.

joostjager · 2025-10-15T08:47:30Z

This PR adds a new async payment benchmark test to integration_tests_rust.rs. The test sets up two nodes with a channel and measures performance while sending 1,000 concurrent payments. It uses Tokio’s multi-threaded runtime to spawn payments as separate async tasks and tracks completion through LDK events. The benchmark provides a simple way to gauge throughput and identify performance bottlenecks in payment handling.

Related: lightningdevkit/rust-lightning#4161

ldk-reviews-bot · 2025-10-15T08:47:33Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

joostjager · 2025-10-21T13:04:00Z

Converted test to criterion benchmark and added it to CI. Also removed the payment throttling, now that it has been established that there is a bug in lightning-net-tokio that causes this. For the benchmark, the 1000 payments can now simply be launched at the same time.

Criterion reports outliers, so this should be able to detect to occassional 30 sec hangs in the payments test.

ldk-reviews-bot · 2025-10-23T13:04:43Z

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-10-25T13:05:28Z

🔔 2nd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-10-27T13:06:14Z

🔔 3rd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

joostjager · 2025-10-28T10:37:23Z

Rebased onto async test framework changes.

tnull · 2025-10-28T13:07:22Z

Mind rebasing once more to fix CI?

tnull

Thanks! The test store changes don't make sense to me, I believe you intended something else there. Otherwise some comments.

tnull · 2025-10-28T13:10:00Z

-	let node = builder.build_with_store(test_sync_store).unwrap();
+	let kv_store: Arc<DynStore> = match config.store_type {
+ TestStoreType::InMemory => {
+ Arc::new(TestSyncStore::new(config.node_config.storage_dir_path.into()))


This doesn't do what you think it does. This is TestSyncStore, a store that writes to multiple backends to ensure they are kept in-sync, not the in-memory TestStore.

Ah, I missed that indeed. Renamed InMemory to TestSyncStore. The intention of the commit is to allow a test/benchmark to run with sqlite (only).

tnull · 2025-10-28T13:21:06Z

+
+	// Spawn each payment as a separate async task
+	task::spawn(async move {
+ println!("{}: Starting payment", payment_hash.0.as_hex());


Are we positive all the printing IO doesn't impact the performance? Should we omit this for 'production' benchmarking?

I did wonder the same. Maybe I should indeed remove it to be sure. Would that be a cfg flag?

Could be, but do we really need them in the first place?

tnull · 2025-10-28T13:24:15Z

+ // Pre-check the HTLC slots to try to avoid the performance impact of a failed payment.
+ while node_a.list_channels()[0].next_outbound_htlc_limit_msat == 0 {
+ println!("{}: Waiting for HTLC slots to free up", payment_hash.0.as_hex());
+ tokio::time::sleep(std::time::Duration::from_millis(100)).await;


How did you determine 100ms here? Do we have an intuition if this could starve any of the waiting payers?

It isn't great indeed. Basically something that looked 'reasonable' to me. I think it is a weakness in the API that a user even needs to do this.

tnull · 2025-10-29T09:48:19Z

+ Arc::new(TestSyncStore::new(config.node_config.storage_dir_path.into()))
+ },
+ TestStoreType::Sqlite => Arc::new(
+ SqliteStore::new(


Let's just use the default build() here, which defaults to SQLite.
If you prefer to have it explicit, feel free to rename build to build_with_sqlite_store and have a new build method on Builder call it. Then you can explicitly set build_with_sqlite_store here.

No, it's alright to use build. Done.

tnull · 2025-10-29T09:50:31Z

+ // Pre-check the HTLC slots to try to avoid the performance impact of a failed payment.
+ while node_a.list_channels()[0].next_outbound_htlc_limit_msat == 0 {
+ println!("{}: Waiting for HTLC slots to free up", payment_hash.0.as_hex());
+ tokio::time::sleep(std::time::Duration::from_millis(100)).await;


tnull · 2025-10-29T09:51:00Z


 vss-client = "0.3"
 prost = { version = "0.11.6", default-features = false}
+criterion = { version = "0.7.0", features = ["async_tokio"] }


Why is this not a dev-dependency?

tnull

Feel free to squash fixups. CI is currently broken with warnings and errors:

warning: unused imports: `KV_TABLE_NAME` and `SQLITE_DB_FILE_NAME`
--> tests/common/mod.rs:32:47
|
32 | use ldk_node::io::sqlite_store::{SqliteStore, KV_TABLE_NAME, SQLITE_DB_FILE_NAME};
| ^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^
|
= note: `#[warn(unused_imports)]` on by default
warning: unused import: `DynStore`
--> tests/common/mod.rs:35:28
|
35 | Builder, CustomTlvRecord, DynStore, Event, LightningBalance, Node, NodeError,
| ^^^^^^^^
error[E0308]: arguments to this function are incorrect
--> tests/benchmarks.rs:185:15
|
185 | total += send_payments(node_a, node_b).await;
| ^^^^^^^^^^^^^
|
note: expected `Arc<Node>`, found `Arc<Arc<Node>>`
--> tests/benchmarks.rs:185:29
|
185 | total += send_payments(node_a, node_b).await;
| ^^^^^^
= note: expected struct `Arc<ldk_node::Node>`
found struct `Arc<Arc<ldk_node::Node>>`
note: expected `Arc<Node>`, found `Arc<Arc<Node>>`
--> tests/benchmarks.rs:185:37
|
185 | total += send_payments(node_a, node_b).await;
| ^^^^^^
= note: expected struct `Arc<ldk_node::Node>`
found struct `Arc<Arc<ldk_node::Node>>`
note: function defined here
--> tests/benchmarks.rs:63:10
|
63 | async fn send_payments(node_a: Arc<Node>, node_b: Arc<Node>) -> std::time::Duration {
| ^^^^^^^^^^^^^ ----------------- -----------------

To enable more realistic testing with sqlite as a backend.

joostjager · 2025-10-31T15:20:30Z

Had to move the code to the standard benches folder, which is better anyway.

tnull

LGTM, please squash.

Introduces a criterion-based benchmark that sends 1000 concurrent payments between two LDK nodes to measure total duration. Also adds a CI job to automatically run the benchmark.

joostjager · 2025-10-15T08:47:30Z

This PR adds a new async payment benchmark test to integration_tests_rust.rs. The test sets up two nodes with a channel and measures performance while sending 1,000 concurrent payments. It uses Tokio’s multi-threaded runtime to spawn payments as separate async tasks and tracks completion through LDK events. The benchmark provides a simple way to gauge throughput and identify performance bottlenecks in payment handling.

Related: lightningdevkit/rust-lightning#4161

ldk-reviews-bot · 2025-10-15T08:47:33Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

joostjager · 2025-10-21T13:04:00Z

Converted test to criterion benchmark and added it to CI. Also removed the payment throttling, now that it has been established that there is a bug in lightning-net-tokio that causes this. For the benchmark, the 1000 payments can now simply be launched at the same time.

Criterion reports outliers, so this should be able to detect to occassional 30 sec hangs in the payments test.

ldk-reviews-bot · 2025-10-23T13:04:43Z

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-10-25T13:05:28Z

🔔 2nd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-10-27T13:06:14Z

🔔 3rd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

joostjager · 2025-10-28T10:37:23Z

Rebased onto async test framework changes.

tnull · 2025-10-28T13:07:22Z

Mind rebasing once more to fix CI?

tnull

Thanks! The test store changes don't make sense to me, I believe you intended something else there. Otherwise some comments.

tnull · 2025-10-28T13:10:00Z

-	let node = builder.build_with_store(test_sync_store).unwrap();
+	let kv_store: Arc<DynStore> = match config.store_type {
+ TestStoreType::InMemory => {
+ Arc::new(TestSyncStore::new(config.node_config.storage_dir_path.into()))


This doesn't do what you think it does. This is TestSyncStore, a store that writes to multiple backends to ensure they are kept in-sync, not the in-memory TestStore.

Ah, I missed that indeed. Renamed InMemory to TestSyncStore. The intention of the commit is to allow a test/benchmark to run with sqlite (only).

tnull · 2025-10-28T13:21:06Z

+
+	// Spawn each payment as a separate async task
+	task::spawn(async move {
+ println!("{}: Starting payment", payment_hash.0.as_hex());


Are we positive all the printing IO doesn't impact the performance? Should we omit this for 'production' benchmarking?

I did wonder the same. Maybe I should indeed remove it to be sure. Would that be a cfg flag?

Could be, but do we really need them in the first place?

tnull · 2025-10-28T13:24:15Z

+ // Pre-check the HTLC slots to try to avoid the performance impact of a failed payment.
+ while node_a.list_channels()[0].next_outbound_htlc_limit_msat == 0 {
+ println!("{}: Waiting for HTLC slots to free up", payment_hash.0.as_hex());
+ tokio::time::sleep(std::time::Duration::from_millis(100)).await;


How did you determine 100ms here? Do we have an intuition if this could starve any of the waiting payers?

It isn't great indeed. Basically something that looked 'reasonable' to me. I think it is a weakness in the API that a user even needs to do this.

tnull · 2025-10-29T09:48:19Z

+ Arc::new(TestSyncStore::new(config.node_config.storage_dir_path.into()))
+ },
+ TestStoreType::Sqlite => Arc::new(
+ SqliteStore::new(


Let's just use the default build() here, which defaults to SQLite.
If you prefer to have it explicit, feel free to rename build to build_with_sqlite_store and have a new build method on Builder call it. Then you can explicitly set build_with_sqlite_store here.

No, it's alright to use build. Done.

tnull · 2025-10-29T09:50:31Z

+ // Pre-check the HTLC slots to try to avoid the performance impact of a failed payment.
+ while node_a.list_channels()[0].next_outbound_htlc_limit_msat == 0 {
+ println!("{}: Waiting for HTLC slots to free up", payment_hash.0.as_hex());
+ tokio::time::sleep(std::time::Duration::from_millis(100)).await;


tnull · 2025-10-29T09:51:00Z


 vss-client = "0.3"
 prost = { version = "0.11.6", default-features = false}
+criterion = { version = "0.7.0", features = ["async_tokio"] }


Why is this not a dev-dependency?

tnull

Feel free to squash fixups. CI is currently broken with warnings and errors:

warning: unused imports: `KV_TABLE_NAME` and `SQLITE_DB_FILE_NAME`
--> tests/common/mod.rs:32:47
|
32 | use ldk_node::io::sqlite_store::{SqliteStore, KV_TABLE_NAME, SQLITE_DB_FILE_NAME};
| ^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^
|
= note: `#[warn(unused_imports)]` on by default
warning: unused import: `DynStore`
--> tests/common/mod.rs:35:28
|
35 | Builder, CustomTlvRecord, DynStore, Event, LightningBalance, Node, NodeError,
| ^^^^^^^^
error[E0308]: arguments to this function are incorrect
--> tests/benchmarks.rs:185:15
|
185 | total += send_payments(node_a, node_b).await;
| ^^^^^^^^^^^^^
|
note: expected `Arc<Node>`, found `Arc<Arc<Node>>`
--> tests/benchmarks.rs:185:29
|
185 | total += send_payments(node_a, node_b).await;
| ^^^^^^
= note: expected struct `Arc<ldk_node::Node>`
found struct `Arc<Arc<ldk_node::Node>>`
note: expected `Arc<Node>`, found `Arc<Arc<Node>>`
--> tests/benchmarks.rs:185:37
|
185 | total += send_payments(node_a, node_b).await;
| ^^^^^^
= note: expected struct `Arc<ldk_node::Node>`
found struct `Arc<Arc<ldk_node::Node>>`
note: function defined here
--> tests/benchmarks.rs:63:10
|
63 | async fn send_payments(node_a: Arc<Node>, node_b: Arc<Node>) -> std::time::Duration {
| ^^^^^^^^^^^^^ ----------------- -----------------

To enable more realistic testing with sqlite as a backend.

joostjager · 2025-10-31T15:20:30Z

Had to move the code to the standard benches folder, which is better anyway.

tnull

LGTM, please squash.

Introduces a criterion-based benchmark that sends 1000 concurrent payments between two LDK nodes to measure total duration. Also adds a CI job to automatically run the benchmark.

joostjager · 2025-10-15T08:47:30Z

This PR adds a new async payment benchmark test to integration_tests_rust.rs. The test sets up two nodes with a channel and measures performance while sending 1,000 concurrent payments. It uses Tokio’s multi-threaded runtime to spawn payments as separate async tasks and tracks completion through LDK events. The benchmark provides a simple way to gauge throughput and identify performance bottlenecks in payment handling.

Related: lightningdevkit/rust-lightning#4161

ldk-reviews-bot · 2025-10-15T08:47:33Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

joostjager · 2025-10-21T13:04:00Z

Converted test to criterion benchmark and added it to CI. Also removed the payment throttling, now that it has been established that there is a bug in lightning-net-tokio that causes this. For the benchmark, the 1000 payments can now simply be launched at the same time.

Criterion reports outliers, so this should be able to detect to occassional 30 sec hangs in the payments test.

ldk-reviews-bot · 2025-10-23T13:04:43Z

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-10-25T13:05:28Z

🔔 2nd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-10-27T13:06:14Z

🔔 3rd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

joostjager · 2025-10-28T10:37:23Z

Rebased onto async test framework changes.

tnull · 2025-10-28T13:07:22Z

Mind rebasing once more to fix CI?

tnull

Thanks! The test store changes don't make sense to me, I believe you intended something else there. Otherwise some comments.

tnull · 2025-10-28T13:10:00Z

-	let node = builder.build_with_store(test_sync_store).unwrap();
+	let kv_store: Arc<DynStore> = match config.store_type {
+ TestStoreType::InMemory => {
+ Arc::new(TestSyncStore::new(config.node_config.storage_dir_path.into()))


This doesn't do what you think it does. This is TestSyncStore, a store that writes to multiple backends to ensure they are kept in-sync, not the in-memory TestStore.

Ah, I missed that indeed. Renamed InMemory to TestSyncStore. The intention of the commit is to allow a test/benchmark to run with sqlite (only).

tnull · 2025-10-28T13:21:06Z

+
+	// Spawn each payment as a separate async task
+	task::spawn(async move {
+ println!("{}: Starting payment", payment_hash.0.as_hex());


Are we positive all the printing IO doesn't impact the performance? Should we omit this for 'production' benchmarking?

I did wonder the same. Maybe I should indeed remove it to be sure. Would that be a cfg flag?

Could be, but do we really need them in the first place?

tnull · 2025-10-28T13:24:15Z

+ // Pre-check the HTLC slots to try to avoid the performance impact of a failed payment.
+ while node_a.list_channels()[0].next_outbound_htlc_limit_msat == 0 {
+ println!("{}: Waiting for HTLC slots to free up", payment_hash.0.as_hex());
+ tokio::time::sleep(std::time::Duration::from_millis(100)).await;


How did you determine 100ms here? Do we have an intuition if this could starve any of the waiting payers?

It isn't great indeed. Basically something that looked 'reasonable' to me. I think it is a weakness in the API that a user even needs to do this.

tnull · 2025-10-29T09:48:19Z

+ Arc::new(TestSyncStore::new(config.node_config.storage_dir_path.into()))
+ },
+ TestStoreType::Sqlite => Arc::new(
+ SqliteStore::new(


Let's just use the default build() here, which defaults to SQLite.
If you prefer to have it explicit, feel free to rename build to build_with_sqlite_store and have a new build method on Builder call it. Then you can explicitly set build_with_sqlite_store here.

No, it's alright to use build. Done.

tnull · 2025-10-29T09:50:31Z

+ // Pre-check the HTLC slots to try to avoid the performance impact of a failed payment.
+ while node_a.list_channels()[0].next_outbound_htlc_limit_msat == 0 {
+ println!("{}: Waiting for HTLC slots to free up", payment_hash.0.as_hex());
+ tokio::time::sleep(std::time::Duration::from_millis(100)).await;


tnull · 2025-10-29T09:51:00Z


 vss-client = "0.3"
 prost = { version = "0.11.6", default-features = false}
+criterion = { version = "0.7.0", features = ["async_tokio"] }


Why is this not a dev-dependency?

tnull

Feel free to squash fixups. CI is currently broken with warnings and errors:

warning: unused imports: `KV_TABLE_NAME` and `SQLITE_DB_FILE_NAME`
--> tests/common/mod.rs:32:47
|
32 | use ldk_node::io::sqlite_store::{SqliteStore, KV_TABLE_NAME, SQLITE_DB_FILE_NAME};
| ^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^
|
= note: `#[warn(unused_imports)]` on by default
warning: unused import: `DynStore`
--> tests/common/mod.rs:35:28
|
35 | Builder, CustomTlvRecord, DynStore, Event, LightningBalance, Node, NodeError,
| ^^^^^^^^
error[E0308]: arguments to this function are incorrect
--> tests/benchmarks.rs:185:15
|
185 | total += send_payments(node_a, node_b).await;
| ^^^^^^^^^^^^^
|
note: expected `Arc<Node>`, found `Arc<Arc<Node>>`
--> tests/benchmarks.rs:185:29
|
185 | total += send_payments(node_a, node_b).await;
| ^^^^^^
= note: expected struct `Arc<ldk_node::Node>`
found struct `Arc<Arc<ldk_node::Node>>`
note: expected `Arc<Node>`, found `Arc<Arc<Node>>`
--> tests/benchmarks.rs:185:37
|
185 | total += send_payments(node_a, node_b).await;
| ^^^^^^
= note: expected struct `Arc<ldk_node::Node>`
found struct `Arc<Arc<ldk_node::Node>>`
note: function defined here
--> tests/benchmarks.rs:63:10
|
63 | async fn send_payments(node_a: Arc<Node>, node_b: Arc<Node>) -> std::time::Duration {
| ^^^^^^^^^^^^^ ----------------- -----------------

To enable more realistic testing with sqlite as a backend.

joostjager · 2025-10-31T15:20:30Z

Had to move the code to the standard benches folder, which is better anyway.

tnull

LGTM, please squash.

Introduces a criterion-based benchmark that sends 1000 concurrent payments between two LDK nodes to measure total duration. Also adds a CI job to automatically run the benchmark.

joostjager · 2025-10-15T08:47:30Z

This PR adds a new async payment benchmark test to integration_tests_rust.rs. The test sets up two nodes with a channel and measures performance while sending 1,000 concurrent payments. It uses Tokio’s multi-threaded runtime to spawn payments as separate async tasks and tracks completion through LDK events. The benchmark provides a simple way to gauge throughput and identify performance bottlenecks in payment handling.

Related: lightningdevkit/rust-lightning#4161

ldk-reviews-bot · 2025-10-15T08:47:33Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

joostjager · 2025-10-21T13:04:00Z

Converted test to criterion benchmark and added it to CI. Also removed the payment throttling, now that it has been established that there is a bug in lightning-net-tokio that causes this. For the benchmark, the 1000 payments can now simply be launched at the same time.

Criterion reports outliers, so this should be able to detect to occassional 30 sec hangs in the payments test.

ldk-reviews-bot · 2025-10-23T13:04:43Z

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-10-25T13:05:28Z

🔔 2nd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-10-27T13:06:14Z

🔔 3rd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

joostjager · 2025-10-28T10:37:23Z

Rebased onto async test framework changes.

tnull · 2025-10-28T13:07:22Z

Mind rebasing once more to fix CI?

tnull

Thanks! The test store changes don't make sense to me, I believe you intended something else there. Otherwise some comments.

tnull · 2025-10-28T13:10:00Z

-	let node = builder.build_with_store(test_sync_store).unwrap();
+	let kv_store: Arc<DynStore> = match config.store_type {
+ TestStoreType::InMemory => {
+ Arc::new(TestSyncStore::new(config.node_config.storage_dir_path.into()))


This doesn't do what you think it does. This is TestSyncStore, a store that writes to multiple backends to ensure they are kept in-sync, not the in-memory TestStore.

Ah, I missed that indeed. Renamed InMemory to TestSyncStore. The intention of the commit is to allow a test/benchmark to run with sqlite (only).

tnull · 2025-10-28T13:21:06Z

+
+	// Spawn each payment as a separate async task
+	task::spawn(async move {
+ println!("{}: Starting payment", payment_hash.0.as_hex());


Are we positive all the printing IO doesn't impact the performance? Should we omit this for 'production' benchmarking?

I did wonder the same. Maybe I should indeed remove it to be sure. Would that be a cfg flag?

Could be, but do we really need them in the first place?

tnull · 2025-10-28T13:24:15Z

+ // Pre-check the HTLC slots to try to avoid the performance impact of a failed payment.
+ while node_a.list_channels()[0].next_outbound_htlc_limit_msat == 0 {
+ println!("{}: Waiting for HTLC slots to free up", payment_hash.0.as_hex());
+ tokio::time::sleep(std::time::Duration::from_millis(100)).await;


How did you determine 100ms here? Do we have an intuition if this could starve any of the waiting payers?

It isn't great indeed. Basically something that looked 'reasonable' to me. I think it is a weakness in the API that a user even needs to do this.

tnull · 2025-10-29T09:48:19Z

+ Arc::new(TestSyncStore::new(config.node_config.storage_dir_path.into()))
+ },
+ TestStoreType::Sqlite => Arc::new(
+ SqliteStore::new(


Let's just use the default build() here, which defaults to SQLite.
If you prefer to have it explicit, feel free to rename build to build_with_sqlite_store and have a new build method on Builder call it. Then you can explicitly set build_with_sqlite_store here.

No, it's alright to use build. Done.

tnull · 2025-10-29T09:50:31Z

+ // Pre-check the HTLC slots to try to avoid the performance impact of a failed payment.
+ while node_a.list_channels()[0].next_outbound_htlc_limit_msat == 0 {
+ println!("{}: Waiting for HTLC slots to free up", payment_hash.0.as_hex());
+ tokio::time::sleep(std::time::Duration::from_millis(100)).await;


tnull · 2025-10-29T09:51:00Z


 vss-client = "0.3"
 prost = { version = "0.11.6", default-features = false}
+criterion = { version = "0.7.0", features = ["async_tokio"] }


Why is this not a dev-dependency?

tnull

Feel free to squash fixups. CI is currently broken with warnings and errors:

warning: unused imports: `KV_TABLE_NAME` and `SQLITE_DB_FILE_NAME`
--> tests/common/mod.rs:32:47
|
32 | use ldk_node::io::sqlite_store::{SqliteStore, KV_TABLE_NAME, SQLITE_DB_FILE_NAME};
| ^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^
|
= note: `#[warn(unused_imports)]` on by default
warning: unused import: `DynStore`
--> tests/common/mod.rs:35:28
|
35 | Builder, CustomTlvRecord, DynStore, Event, LightningBalance, Node, NodeError,
| ^^^^^^^^
error[E0308]: arguments to this function are incorrect
--> tests/benchmarks.rs:185:15
|
185 | total += send_payments(node_a, node_b).await;
| ^^^^^^^^^^^^^
|
note: expected `Arc<Node>`, found `Arc<Arc<Node>>`
--> tests/benchmarks.rs:185:29
|
185 | total += send_payments(node_a, node_b).await;
| ^^^^^^
= note: expected struct `Arc<ldk_node::Node>`
found struct `Arc<Arc<ldk_node::Node>>`
note: expected `Arc<Node>`, found `Arc<Arc<Node>>`
--> tests/benchmarks.rs:185:37
|
185 | total += send_payments(node_a, node_b).await;
| ^^^^^^
= note: expected struct `Arc<ldk_node::Node>`
found struct `Arc<Arc<ldk_node::Node>>`
note: function defined here
--> tests/benchmarks.rs:63:10
|
63 | async fn send_payments(node_a: Arc<Node>, node_b: Arc<Node>) -> std::time::Duration {
| ^^^^^^^^^^^^^ ----------------- -----------------

To enable more realistic testing with sqlite as a backend.

joostjager · 2025-10-31T15:20:30Z

Had to move the code to the standard benches folder, which is better anyway.

tnull

LGTM, please squash.

Introduces a criterion-based benchmark that sends 1000 concurrent payments between two LDK nodes to measure total duration. Also adds a CI job to automatically run the benchmark.

joostjager force-pushed the payment-benchmark branch from ee6d232 to 53a16a2Compare October 15, 2025 08:48

joostjager mentioned this pull request Oct 15, 2025
Retry payment for local failures lightningdevkit/rust-lightning#4161
Open

joostjager added this to Weekly Goals Oct 16, 2025

joostjager self-assigned this Oct 16, 2025

joostjager force-pushed the payment-benchmark branch 4 times, most recently from fffca97 to 058ede1Compare October 21, 2025 13:01

joostjager marked this pull request as ready for review October 21, 2025 13:04

joostjager requested a review from tnull October 21, 2025 13:04

joostjager force-pushed the payment-benchmark branch from 058ede1 to 6bdb4d0Compare October 21, 2025 13:07

joostjager commented Oct 21, 2025
View reviewed changes

Comment threadCargo.toml Outdated
Comment threadbenches/payments.rs

joostjager removed the request for review from tnull October 28, 2025 09:33

joostjager force-pushed the payment-benchmark branch from 6bdb4d0 to 7a808a5Compare October 28, 2025 10:36

tnull reviewed Oct 28, 2025
View reviewed changes

tnull reviewed Oct 29, 2025
View reviewed changes

joostjager force-pushed the payment-benchmark branch 2 times, most recently from b9fc54d to c231f9dCompare October 30, 2025 14:02

joostjager requested a review from tnull October 30, 2025 14:03

tnull reviewed Oct 31, 2025
View reviewed changes

joostjager force-pushed the payment-benchmark branch from c231f9d to 75e0903Compare October 31, 2025 13:12

Configurable test store
222321d
To enable more realistic testing with sqlite as a backend.

joostjager force-pushed the payment-benchmark branch from 75e0903 to a06dbbbCompare October 31, 2025 15:06

joostjager requested a review from tnull November 3, 2025 08:43

tnull reviewed Nov 3, 2025
View reviewed changes

Add async payment throughput benchmark
14c1cff
Introduces a criterion-based benchmark that sends 1000 concurrent payments between two LDK nodes to measure total duration. Also adds a CI job to automatically run the benchmark.

joostjager force-pushed the payment-benchmark branch from a06dbbb to 14c1cffCompare November 3, 2025 10:40

tnull merged commit 22ae4d2 into lightningdevkit:mainNov 3, 2025
17 checks passed

github-project-automationBot moved this to Done in Weekly Goals Nov 3, 2025

joostjager mentioned this pull request Nov 19, 2025
Add draft changelog for LDK Node v0.7.0 #708
Merged

joostjager force-pushed the payment-benchmark branch from ee6d232 to 53a16a2Compare October 15, 2025 08:48

joostjager mentioned this pull request Oct 15, 2025
Retry payment for local failures lightningdevkit/rust-lightning#4161
Open

joostjager added this to Weekly Goals Oct 16, 2025

joostjager self-assigned this Oct 16, 2025

joostjager force-pushed the payment-benchmark branch 4 times, most recently from fffca97 to 058ede1Compare October 21, 2025 13:01

joostjager marked this pull request as ready for review October 21, 2025 13:04

joostjager requested a review from tnull October 21, 2025 13:04

joostjager force-pushed the payment-benchmark branch from 058ede1 to 6bdb4d0Compare October 21, 2025 13:07

joostjager commented Oct 21, 2025
View reviewed changes

Comment threadCargo.toml Outdated
Comment threadbenches/payments.rs

joostjager removed the request for review from tnull October 28, 2025 09:33

joostjager force-pushed the payment-benchmark branch from 6bdb4d0 to 7a808a5Compare October 28, 2025 10:36

tnull reviewed Oct 28, 2025
View reviewed changes

tnull reviewed Oct 29, 2025
View reviewed changes

joostjager force-pushed the payment-benchmark branch 2 times, most recently from b9fc54d to c231f9dCompare October 30, 2025 14:02

joostjager requested a review from tnull October 30, 2025 14:03

tnull reviewed Oct 31, 2025
View reviewed changes

joostjager force-pushed the payment-benchmark branch from c231f9d to 75e0903Compare October 31, 2025 13:12

Configurable test store
222321d
To enable more realistic testing with sqlite as a backend.

joostjager force-pushed the payment-benchmark branch from 75e0903 to a06dbbbCompare October 31, 2025 15:06

joostjager requested a review from tnull November 3, 2025 08:43

tnull reviewed Nov 3, 2025
View reviewed changes

Add async payment throughput benchmark
14c1cff
Introduces a criterion-based benchmark that sends 1000 concurrent payments between two LDK nodes to measure total duration. Also adds a CI job to automatically run the benchmark.

joostjager force-pushed the payment-benchmark branch from a06dbbb to 14c1cffCompare November 3, 2025 10:40

tnull merged commit 22ae4d2 into lightningdevkit:mainNov 3, 2025
17 checks passed

github-project-automationBot moved this to Done in Weekly Goals Nov 3, 2025

joostjager mentioned this pull request Nov 19, 2025
Add draft changelog for LDK Node v0.7.0 #708
Merged

joostjager force-pushed the payment-benchmark branch from ee6d232 to 53a16a2Compare October 15, 2025 08:48

joostjager mentioned this pull request Oct 15, 2025
Retry payment for local failures lightningdevkit/rust-lightning#4161
Open

joostjager added this to Weekly Goals Oct 16, 2025

joostjager self-assigned this Oct 16, 2025

joostjager force-pushed the payment-benchmark branch 4 times, most recently from fffca97 to 058ede1Compare October 21, 2025 13:01

joostjager marked this pull request as ready for review October 21, 2025 13:04

joostjager requested a review from tnull October 21, 2025 13:04

joostjager force-pushed the payment-benchmark branch from 058ede1 to 6bdb4d0Compare October 21, 2025 13:07

joostjager commented Oct 21, 2025
View reviewed changes

Comment threadCargo.toml Outdated
Comment threadbenches/payments.rs

joostjager removed the request for review from tnull October 28, 2025 09:33

joostjager force-pushed the payment-benchmark branch from 6bdb4d0 to 7a808a5Compare October 28, 2025 10:36

tnull reviewed Oct 28, 2025
View reviewed changes

tnull reviewed Oct 29, 2025
View reviewed changes

joostjager force-pushed the payment-benchmark branch 2 times, most recently from b9fc54d to c231f9dCompare October 30, 2025 14:02

joostjager requested a review from tnull October 30, 2025 14:03

tnull reviewed Oct 31, 2025
View reviewed changes

joostjager force-pushed the payment-benchmark branch from c231f9d to 75e0903Compare October 31, 2025 13:12

Configurable test store
222321d
To enable more realistic testing with sqlite as a backend.

joostjager force-pushed the payment-benchmark branch from 75e0903 to a06dbbbCompare October 31, 2025 15:06

joostjager requested a review from tnull November 3, 2025 08:43

tnull reviewed Nov 3, 2025
View reviewed changes

Add async payment throughput benchmark
14c1cff
Introduces a criterion-based benchmark that sends 1000 concurrent payments between two LDK nodes to measure total duration. Also adds a CI job to automatically run the benchmark.

joostjager force-pushed the payment-benchmark branch from a06dbbb to 14c1cffCompare November 3, 2025 10:40

tnull merged commit 22ae4d2 into lightningdevkit:mainNov 3, 2025
17 checks passed

github-project-automationBot moved this to Done in Weekly Goals Nov 3, 2025

joostjager mentioned this pull request Nov 19, 2025
Add draft changelog for LDK Node v0.7.0 #708
Merged

joostjager force-pushed the payment-benchmark branch from ee6d232 to 53a16a2Compare October 15, 2025 08:48

joostjager mentioned this pull request Oct 15, 2025
Retry payment for local failures lightningdevkit/rust-lightning#4161
Open

joostjager added this to Weekly Goals Oct 16, 2025

joostjager self-assigned this Oct 16, 2025

joostjager force-pushed the payment-benchmark branch 4 times, most recently from fffca97 to 058ede1Compare October 21, 2025 13:01

joostjager marked this pull request as ready for review October 21, 2025 13:04

joostjager requested a review from tnull October 21, 2025 13:04

joostjager force-pushed the payment-benchmark branch from 058ede1 to 6bdb4d0Compare October 21, 2025 13:07

joostjager commented Oct 21, 2025
View reviewed changes

Comment threadCargo.toml Outdated
Comment threadbenches/payments.rs

joostjager removed the request for review from tnull October 28, 2025 09:33

joostjager force-pushed the payment-benchmark branch from 6bdb4d0 to 7a808a5Compare October 28, 2025 10:36

tnull reviewed Oct 28, 2025
View reviewed changes

tnull reviewed Oct 29, 2025
View reviewed changes

joostjager force-pushed the payment-benchmark branch 2 times, most recently from b9fc54d to c231f9dCompare October 30, 2025 14:02

joostjager requested a review from tnull October 30, 2025 14:03

tnull reviewed Oct 31, 2025
View reviewed changes

joostjager force-pushed the payment-benchmark branch from c231f9d to 75e0903Compare October 31, 2025 13:12

Configurable test store
222321d
To enable more realistic testing with sqlite as a backend.

joostjager force-pushed the payment-benchmark branch from 75e0903 to a06dbbbCompare October 31, 2025 15:06

joostjager requested a review from tnull November 3, 2025 08:43

tnull reviewed Nov 3, 2025
View reviewed changes

Add async payment throughput benchmark
14c1cff
Introduces a criterion-based benchmark that sends 1000 concurrent payments between two LDK nodes to measure total duration. Also adds a CI job to automatically run the benchmark.

joostjager force-pushed the payment-benchmark branch from a06dbbb to 14c1cffCompare November 3, 2025 10:40

tnull merged commit 22ae4d2 into lightningdevkit:mainNov 3, 2025
17 checks passed

github-project-automationBot moved this to Done in Weekly Goals Nov 3, 2025

joostjager mentioned this pull request Nov 19, 2025
Add draft changelog for LDK Node v0.7.0 #708
Merged

joostjager force-pushed the payment-benchmark branch from ee6d232 to 53a16a2Compare October 15, 2025 08:48

joostjager mentioned this pull request Oct 15, 2025
Retry payment for local failures lightningdevkit/rust-lightning#4161
Open

joostjager added this to Weekly Goals Oct 16, 2025

joostjager self-assigned this Oct 16, 2025

joostjager force-pushed the payment-benchmark branch 4 times, most recently from fffca97 to 058ede1Compare October 21, 2025 13:01

joostjager marked this pull request as ready for review October 21, 2025 13:04

joostjager requested a review from tnull October 21, 2025 13:04

joostjager force-pushed the payment-benchmark branch from 058ede1 to 6bdb4d0Compare October 21, 2025 13:07

joostjager commented Oct 21, 2025
View reviewed changes

Comment threadCargo.toml Outdated
Comment threadbenches/payments.rs

joostjager removed the request for review from tnull October 28, 2025 09:33

joostjager force-pushed the payment-benchmark branch from 6bdb4d0 to 7a808a5Compare October 28, 2025 10:36

tnull reviewed Oct 28, 2025
View reviewed changes

tnull reviewed Oct 29, 2025
View reviewed changes

joostjager force-pushed the payment-benchmark branch 2 times, most recently from b9fc54d to c231f9dCompare October 30, 2025 14:02

joostjager requested a review from tnull October 30, 2025 14:03

tnull reviewed Oct 31, 2025
View reviewed changes

joostjager force-pushed the payment-benchmark branch from c231f9d to 75e0903Compare October 31, 2025 13:12

Configurable test store
222321d
To enable more realistic testing with sqlite as a backend.

joostjager force-pushed the payment-benchmark branch from 75e0903 to a06dbbbCompare October 31, 2025 15:06

joostjager requested a review from tnull November 3, 2025 08:43

tnull reviewed Nov 3, 2025
View reviewed changes

Add async payment throughput benchmark
14c1cff
Introduces a criterion-based benchmark that sends 1000 concurrent payments between two LDK nodes to measure total duration. Also adds a CI job to automatically run the benchmark.

joostjager force-pushed the payment-benchmark branch from a06dbbb to 14c1cffCompare November 3, 2025 10:40

tnull merged commit 22ae4d2 into lightningdevkit:mainNov 3, 2025
17 checks passed

github-project-automationBot moved this to Done in Weekly Goals Nov 3, 2025

joostjager mentioned this pull request Nov 19, 2025
Add draft changelog for LDK Node v0.7.0 #708
Merged

joostjager force-pushed the payment-benchmark branch from ee6d232 to 53a16a2Compare October 15, 2025 08:48

joostjager mentioned this pull request Oct 15, 2025
Retry payment for local failures lightningdevkit/rust-lightning#4161
Open

joostjager added this to Weekly Goals Oct 16, 2025

joostjager self-assigned this Oct 16, 2025

joostjager force-pushed the payment-benchmark branch 4 times, most recently from fffca97 to 058ede1Compare October 21, 2025 13:01

joostjager marked this pull request as ready for review October 21, 2025 13:04

joostjager requested a review from tnull October 21, 2025 13:04

joostjager force-pushed the payment-benchmark branch from 058ede1 to 6bdb4d0Compare October 21, 2025 13:07

joostjager commented Oct 21, 2025
View reviewed changes

Comment threadCargo.toml Outdated
Comment threadbenches/payments.rs

joostjager removed the request for review from tnull October 28, 2025 09:33

joostjager force-pushed the payment-benchmark branch from 6bdb4d0 to 7a808a5Compare October 28, 2025 10:36

tnull reviewed Oct 28, 2025
View reviewed changes

tnull reviewed Oct 29, 2025
View reviewed changes

joostjager force-pushed the payment-benchmark branch 2 times, most recently from b9fc54d to c231f9dCompare October 30, 2025 14:02

joostjager requested a review from tnull October 30, 2025 14:03

tnull reviewed Oct 31, 2025
View reviewed changes

joostjager force-pushed the payment-benchmark branch from c231f9d to 75e0903Compare October 31, 2025 13:12

Configurable test store
222321d
To enable more realistic testing with sqlite as a backend.

joostjager force-pushed the payment-benchmark branch from 75e0903 to a06dbbbCompare October 31, 2025 15:06

joostjager requested a review from tnull November 3, 2025 08:43

tnull reviewed Nov 3, 2025
View reviewed changes

Add async payment throughput benchmark
14c1cff
Introduces a criterion-based benchmark that sends 1000 concurrent payments between two LDK nodes to measure total duration. Also adds a CI job to automatically run the benchmark.

joostjager force-pushed the payment-benchmark branch from a06dbbb to 14c1cffCompare November 3, 2025 10:40

tnull merged commit 22ae4d2 into lightningdevkit:mainNov 3, 2025
17 checks passed

github-project-automationBot moved this to Done in Weekly Goals Nov 3, 2025

joostjager mentioned this pull request Nov 19, 2025
Add draft changelog for LDK Node v0.7.0 #708
Merged

joostjager force-pushed the payment-benchmark branch from ee6d232 to 53a16a2Compare October 15, 2025 08:48

joostjager mentioned this pull request Oct 15, 2025
Retry payment for local failures lightningdevkit/rust-lightning#4161
Open

joostjager added this to Weekly Goals Oct 16, 2025

joostjager self-assigned this Oct 16, 2025

joostjager force-pushed the payment-benchmark branch 4 times, most recently from fffca97 to 058ede1Compare October 21, 2025 13:01

joostjager marked this pull request as ready for review October 21, 2025 13:04

joostjager requested a review from tnull October 21, 2025 13:04

joostjager force-pushed the payment-benchmark branch from 058ede1 to 6bdb4d0Compare October 21, 2025 13:07

joostjager commented Oct 21, 2025
View reviewed changes

Comment threadCargo.toml Outdated
Comment threadbenches/payments.rs

joostjager removed the request for review from tnull October 28, 2025 09:33

joostjager force-pushed the payment-benchmark branch from 6bdb4d0 to 7a808a5Compare October 28, 2025 10:36

tnull reviewed Oct 28, 2025
View reviewed changes

tnull reviewed Oct 29, 2025
View reviewed changes

joostjager force-pushed the payment-benchmark branch 2 times, most recently from b9fc54d to c231f9dCompare October 30, 2025 14:02

joostjager requested a review from tnull October 30, 2025 14:03

tnull reviewed Oct 31, 2025
View reviewed changes

joostjager force-pushed the payment-benchmark branch from c231f9d to 75e0903Compare October 31, 2025 13:12

Configurable test store
222321d
To enable more realistic testing with sqlite as a backend.

joostjager force-pushed the payment-benchmark branch from 75e0903 to a06dbbbCompare October 31, 2025 15:06

joostjager requested a review from tnull November 3, 2025 08:43

tnull reviewed Nov 3, 2025
View reviewed changes

Add async payment throughput benchmark
14c1cff
Introduces a criterion-based benchmark that sends 1000 concurrent payments between two LDK nodes to measure total duration. Also adds a CI job to automatically run the benchmark.

joostjager force-pushed the payment-benchmark branch from a06dbbb to 14c1cffCompare November 3, 2025 10:40

tnull merged commit 22ae4d2 into lightningdevkit:mainNov 3, 2025
17 checks passed

github-project-automationBot moved this to Done in Weekly Goals Nov 3, 2025

joostjager mentioned this pull request Nov 19, 2025
Add draft changelog for LDK Node v0.7.0 #708
Merged

joostjager force-pushed the payment-benchmark branch from ee6d232 to 53a16a2Compare October 15, 2025 08:48

joostjager mentioned this pull request Oct 15, 2025
Retry payment for local failures lightningdevkit/rust-lightning#4161
Open

joostjager added this to Weekly Goals Oct 16, 2025

joostjager self-assigned this Oct 16, 2025

joostjager force-pushed the payment-benchmark branch 4 times, most recently from fffca97 to 058ede1Compare October 21, 2025 13:01

joostjager marked this pull request as ready for review October 21, 2025 13:04

joostjager requested a review from tnull October 21, 2025 13:04

joostjager force-pushed the payment-benchmark branch from 058ede1 to 6bdb4d0Compare October 21, 2025 13:07

joostjager commented Oct 21, 2025
View reviewed changes

Comment threadCargo.toml Outdated
Comment threadbenches/payments.rs

joostjager removed the request for review from tnull October 28, 2025 09:33

joostjager force-pushed the payment-benchmark branch from 6bdb4d0 to 7a808a5Compare October 28, 2025 10:36

tnull reviewed Oct 28, 2025
View reviewed changes

tnull reviewed Oct 29, 2025
View reviewed changes

joostjager force-pushed the payment-benchmark branch 2 times, most recently from b9fc54d to c231f9dCompare October 30, 2025 14:02

joostjager requested a review from tnull October 30, 2025 14:03

tnull reviewed Oct 31, 2025
View reviewed changes

joostjager force-pushed the payment-benchmark branch from c231f9d to 75e0903Compare October 31, 2025 13:12

Configurable test store
222321d
To enable more realistic testing with sqlite as a backend.

joostjager force-pushed the payment-benchmark branch from 75e0903 to a06dbbbCompare October 31, 2025 15:06

joostjager requested a review from tnull November 3, 2025 08:43

tnull reviewed Nov 3, 2025
View reviewed changes

Add async payment throughput benchmark
14c1cff
Introduces a criterion-based benchmark that sends 1000 concurrent payments between two LDK nodes to measure total duration. Also adds a CI job to automatically run the benchmark.

joostjager force-pushed the payment-benchmark branch from a06dbbb to 14c1cffCompare November 3, 2025 10:40

tnull merged commit 22ae4d2 into lightningdevkit:mainNov 3, 2025
17 checks passed

github-project-automationBot moved this to Done in Weekly Goals Nov 3, 2025

joostjager mentioned this pull request Nov 19, 2025
Add draft changelog for LDK Node v0.7.0 #708
Merged

Uh oh!

Conversation

joostjager commented Oct 15, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ldk-reviews-bot commented Oct 15, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

joostjager commented Oct 21, 2025

Uh oh!

Uh oh!

Uh oh!

ldk-reviews-bot commented Oct 23, 2025

Uh oh!

ldk-reviews-bot commented Oct 25, 2025

Uh oh!

ldk-reviews-bot commented Oct 27, 2025

Uh oh!

joostjager commented Oct 28, 2025

Uh oh!

tnull commented Oct 28, 2025

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

joostjager commented Oct 31, 2025

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

joostjager commented Oct 15, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ldk-reviews-bot commented Oct 15, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

joostjager commented Oct 15, 2025•
edited
Loading

ldk-reviews-bot commented Oct 15, 2025•
edited
Loading

joostjager commented Oct 15, 2025•
edited
Loading

ldk-reviews-bot commented Oct 15, 2025•
edited
Loading