feat(background-processor): introduce builder for `BackgroundProcessor` and `process_events_async` #3688

Anyitechs · 2025-03-28T08:01:55Z

This PR introduces two main improvements to the BackgroundProcessor and process_events_async:

Adds a BackgroundProcessorConfigBuilder and BackgroundProcessorConfigAsyncBuilder for a more ergonomic way to construct a BackgroundProcessor and it's async variant (process_events_async), and supports optional parameters through builder methods
Introduces BackgroundProcessorConfig and BackgroundProcessorConfigAsync to standardize configuration for the sync (BackgroundProcessor) and async (process_events_async) variant. The Builder returns this config object, which can be used to start the event via BackgroundProcessor::start and process_events_async

ldk-reviews-bot · 2025-03-28T08:01:58Z

👋 I see @joostjager was un-assigned.
If you'd like another reviewer assignemnt, please click here.

tnull

Already looks pretty good, one question though.

Also, do you have any idea how we could solve the same issue for the async variant of the background processor, i.e., for the optional arguments of process_events_async?

tnull · 2025-03-28T08:14:17Z

lightning-background-processor/src/lib.rs

 	}
+
+	/// Creates a new [`BackgroundProcessorBuilder`] to construct a   [`BackgroundProcessor`] with optional components.
+	pub fn builder<'a, PS, EH, M, CM, PGS, RGS, G, UL, L, PM>(


I'm a bit confused on the purpose of this method: in which scenario would we already have a working BackgroundProcessor to call builder on, just to then use the BackgroundProcessorBuilder to create yet another BackgroundProcessor?

This is confusing indeed. I was thinking the BackgroundProcessorBuilder::new() can be an internal method and accessible via builder, but it doesn't make sense. I will remove the builder method here and allow users use BackgroundProcessorBuilder::new() directly.

@tnull this doesn't take self, though?

Either way, normally the builder pattern has the builder() associated function, but works something like:
BackgroundProcessor::builder() constructs a BackgroundProcessorBuilder with "default" fields (which might be hard in this case), and you would not have any parameters for builder().

So yeah, probably removing this is best.

@tnull this doesn't take self, though?

Ah true.

Either way, normally the builder pattern has the builder() associated function, but works something like: BackgroundProcessor::builder() constructs a BackgroundProcessorBuilder with "default" fields (which might be hard in this case), and you would not have any parameters for builder().

Yeah, unclear what defaults would be.

ldk-reviews-bot · 2025-03-28T08:16:53Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

Anyitechs · 2025-03-28T09:00:13Z

Already looks pretty good, one question though.

Also, do you have any idea how we could solve the same issue for the async variant of the background processor, i.e., for the optional arguments of process_events_async?

Yea, I think we can extend the new BackgroundProcessorBuilder or provide a new builder for the async variant. But extending the new builder might be the better approach as we can avoid duplicating the builder logic since the sync and async variants share the same optional components.

tnull · 2025-03-28T09:07:32Z

Yea, I think we can extend the new BackgroundProcessorBuilder or provide a new builder for the async variant. But extending the new builder might be the better approach as we can avoid duplicating the builder logic since the sync and async variants share the same optional components.

The question is how this would work? process_events_async is just a method that users need to call regularly, so to 'build' it with different configuration you'd need to provide multiple versions of it, which can get messy real quick, essentially exactly the thing we tried to avoid with the builder pattern. It makes me wonder if we should introduce a BackgroundProcessorParams/BackgroundProcessorConfig object that process_events_async takes as its only argument. And if we do so, maybe we should/could reuse the same object for the non-async BackgroundProcessor, also? Meaning, this object could either replace the builder or we could have the builder return the new config object.

What do you think?

Anyitechs · 2025-03-28T09:53:33Z

Yea, I think we can extend the new BackgroundProcessorBuilder or provide a new builder for the async variant. But extending the new builder might be the better approach as we can avoid duplicating the builder logic since the sync and async variants share the same optional components.

The question is how this would work? process_events_async is just a method that users need to call regularly, so to 'build' it with different configuration you'd need to provide multiple versions of it, which can get messy real quick, essentially exactly the thing we tried to avoid with the builder pattern. It makes me wonder if we should introduce a BackgroundProcessorParams/BackgroundProcessorConfig object that process_events_async takes as its only argument. And if we do so, maybe we should/could reuse the same object for the non-async BackgroundProcessor, also? Meaning, this object could either replace the builder or we could have the builder return the new config object.

What do you think?

Thank you for the suggestion. I agree that introducing a BackgroundProcessorConfig object would be a better option. I'm thinking we can reuse the same object for both variants and have the builder return the new config object.

What do you think about that?

tnull · 2025-03-28T10:02:54Z

What do you think about that?

Sounds good to me, although we might need to account for the fact that the two variants have slightly different type requirements (i.e., trait bounds). But I think we should be able to accommodate that via feature-gates on std and/or futures.

Anyitechs · 2025-03-28T10:17:20Z

Sounds good to me, although we might need to account for the fact that the two variants have slightly different type requirements (i.e., trait bounds). But I think we should be able to accommodate that via feature-gates on std and/or futures.

Yes, that can be handled conditionally using feature-gates.

I guess I can go ahead with the implementation, right?

Anyitechs · 2025-04-09T17:11:46Z

This PR is ready for another round of review.

tnull · 2025-04-10T09:23:21Z

lightning-background-processor/src/lib.rs

-	onion_messenger: Option<OM>, gossip_sync: GossipSync<PGS, RGS, G, UL, L>, peer_manager: PM,
-	logger: L, scorer: Option<S>, sleeper: Sleeper, mobile_interruptable_platform: bool,
-	fetch_time: FetchTime,
+	config: BackgroundProcessorConfig<


nit: I think we might want to add a #[rustfmt::skip] here/above to avoid having rustfmt making this that vertical.

tnull · 2025-04-10T09:26:18Z

lightning-background-processor/src/lib.rs

 	}
 }

+/// Configuration for both synchronous [`BackgroundProcessor`] and asynchronous [`process_events_async`] event processing.


I'm not sure these doc links will work under all circumstances as process_events_async will only be exposed when the futures feature is set. You might need to alter the docs based on the set feature via cfg_attr, see the changes to the background processor docs in #3509 for reference how to do this.

Ah true! Thank you.

tnull · 2025-04-10T09:29:09Z

lightning-background-processor/src/lib.rs

+	_phantom: PhantomData<(&'a (), CF, T, F, P)>,
+}
+
+/// A builder for constructing a [`BackgroundProcessor`] with optional components.


This should say BackgroundProcessorConfig now, no? And do we want to rename the builder to BackgroundProcessorConfigBuilder?

I agree. The builder builds a BackgroundProcessorConfig object, so renaming that to BackgroundProcessorConfigBuilder might be more suitable.

tnull · 2025-04-10T09:29:32Z

lightning-background-processor/src/lib.rs

+	PM::Target: APeerManager + Send + Sync,
+{
+	/// Creates a new builder instance.
+	pub(crate) fn new(


Seems CI is failing due to this being pub(crate)?

tnull · 2025-04-10T09:30:58Z

Did another round of review, will take another look once CI passes.

tnull · 2025-04-10T09:32:18Z

lightning-background-processor/src/lib.rs

+	/// .build();
+	/// let bg_processor = BackgroundProcessor::from_config(config);
+	/// ```
+	pub fn from_config<


I wonder if this should even replace start (i.e., whether we should have start just take a BackgroundProcessorConfig)?

I thought about this too but not sure if we want to make that change on start immediately.

Okay. I think we could drop the parameters from start and really only have it start the background thread, but no strong opinion.

Makes sense. So start takes a BackgroundProcessorConfig, and we can drop the from_config method?

Yeah, it sounds reasoable to have that as the new default constructor, as it should be easier to use anyways. Not sure if somebody else has a different opinion though, may be good to run this by a second reviewer.

Anyitechs · 2025-04-10T10:10:10Z

Did another round of review, will take another look once CI passes.

Thank you very much for the review. I'll address all the feedbacks and update the PR.

ldk-reviews-bot · 2025-04-12T00:00:30Z

🔔 1st Reminder

Hey @dunxen! 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-04-14T00:00:50Z

🔔 2nd Reminder

Hey @dunxen! 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.

Anyitechs · 2025-04-14T14:57:02Z

CI still failing, fixing it.

ldk-reviews-bot · 2025-04-16T00:01:22Z

🔔 3rd Reminder

Hey @dunxen! 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.

dunxen

Thanks! You'll need to run cargo fmt on lightning-background-processor/src/lib.rs and make sure each commit builds fine. You can run this check locally with ./ci/check-each-commit.sh main. It will do an interactive rebase and stop at the first problem commit, which you can fix with appropriate changes, git commit --amend '-S', and then git rebase --continue.

Anyitechs · 2025-04-16T13:59:05Z

Thanks! You'll need to run cargo fmt on lightning-background-processor/src/lib.rs and make sure each commit builds fine. You can run this check locally with ./ci/check-each-commit.sh main. It will do an interactive rebase and stop at the first problem commit, which you can fix with appropriate changes, git commit --amend '-S', and then git rebase --continue.

Thank you so much for the pointer. The email notification was getting much and I looked at the contributing guide severally to see if I can find some info on how to run the CI checks locally, but I couldn't find it.

Happy to add that, if it's worth having.

tnull

It seems CI is still broken due to broken docstest(s) in lightning-background-processor.

tnull

This needs a rebase now that #3509 was merged.

tnull

This unfortunately seems to need another rebase now.

joostjager

I reviewed this as is because I am coming in late as a reviewer. As a primary reviewer, I would have looked more into alternatives (#3688 (comment)). It's a lot of (duplicated) code.

joostjager · 2025-06-16T15:38:00Z

lightning-background-processor/src/lib.rs

 	/// [`Persister::persist_manager`] returns an error. In case of an error, the error is retrieved by calling
 	/// either [`join`] or [`stop`].
 	///
+	/// This method takes a [`BackgroundProcessorConfig`] object that contains all necessary components for


Perhaps some of the docs for start are now better positioned in the config object docs?

joostjager · 2025-06-16T15:39:48Z

lightning-background-processor/src/lib.rs

+	sweeper: Option<OS>,
+	logger: L,
+	scorer: Option<S>,
+	_phantom: PhantomData<(&'a (), CF, T, F, P)>,


Does this need a comment, or do Rust devs immediately understand why it is here?

joostjager · 2025-06-16T15:41:28Z

lightning-background-processor/src/lib.rs

+	}
+
+	/// Builds and returns a [`BackgroundProcessorConfig`] object.
+	pub fn build(


Maybe not doing the builder and just having a config object is worth it to cut down on all the generics and duplication?

But without the builder we’d be back at having the user construct all the objects manually, and also trying to construct a suitableNone value for some of the fields, no?

I mean don't require the build call to copy the object into something immutable. Just use the builder (then not a builder anymore) as the config object itself.

I mean don't require the build call to copy the object into something immutable. Just use the builder (then not a builder anymore) as the config object itself.

Hmm, I'd rather not. The builder pattern is a very common pattern in Rust, and everybody 'knows how it works'. Plus, it of course has the benefit that you don't have to copy anything: as build takes self, move semantics apply and the values are moved to the new object.

Ah, wrong on the copy part. Also no perf consequence obviously here.

But just leaving out .build() isn't that hard? It also isn't as if this config needs to be used in many places. Just once per project. To me all the duplication is already bad enough as it is, and getting rid of some by deviating a bit from a pattern is worth it to me.

Interested to hear @Anyitechs's opinion.

But just leaving out .build() isn't that hard?

This is part of the builder pattern. Without it we Rust devs would be very confused and running in circles tearing out our hair not knowing how to proceed.

It also isn't as if this config needs to be used in many places. Just once per project. To me all the duplication is already bad enough as it is, and getting rid of some by deviating a bit from a pattern is worth it to me.

Interested to hear @Anyitechs's opinion.

I understand your concerns on the duplication, @joostjager. An improved version to help with the duplication would've been to reuse the same config object for the sync and async variant, but that wasn't possible because of the type difference on the trait bounds on some of the components (the EventHandler for example, attempted to handle that via feature-gates but it wasn't successful).

But just leaving out .build() isn't that hard?

I think leaving out .build() will make the API a bit complicated to use.

I am okay then with leaving the builder pattern in, but can you explain me why leaving out .build() makes it complicated?

but can you explain me why leaving out .build() makes it complicated?

I mean leaving it out makes things unclear and users may be unsure when the configuration is complete and it's object ready to use (some users might try to use the builder as the final object). It's conventional to have a .build() method when using the builder pattern as this is what gives the "We're done configuring" signal and allows for final validation.

tnull · 2025-06-20T08:55:29Z

@Anyitechs let us know when you rebased and this is ready for another (hopefully final) look!

…al components

…_async`

lightning-background-processor/src/lib.rs

Anyitechs · 2025-06-20T18:20:29Z

@Anyitechs let us know when you rebased and this is ready for another (hopefully final) look!

Thanks! This PR is ready for another look. Rebased and pushed 2b83ad2 to address @joostjager's comment on the docs update (will squash it in if the changes looks good).

ldk-reviews-bot · 2025-06-23T00:01:03Z

🔔 1st Reminder

Hey @tnull @joostjager! 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-06-23T00:01:04Z

🔔 1st Reminder

Hey @tnull @joostjager! 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.

tnull

Code changes basically LGTM. I also validated that this will work with LDK Node.

However, I unfortunately just realized we currently still require the user to always provide values, even those who are/should be optional.

For example, if I just remove one with_ call from tests:

diff --git a/lightning-background-processor/src/lib.rs b/lightning-background-processor/src/lib.rs
index eb0cbbf1e..6264746c2 100644
--- a/lightning-background-processor/src/lib.rs
+++ b/lightning-background-processor/src/lib.rs
@@ -2947,7 +2947,6 @@ mod tests {
                builder
                        .with_onion_messenger(Arc::clone(&nodes[0].messenger))
                        .with_scorer(Arc::clone(&nodes[0].scorer))
-                       .with_liquidity_manager(Arc::clone(&nodes[0].liquidity_manager))
                        .with_sweeper(Arc::clone(&nodes[0].sweeper));

                let config = builder.build();

we still get the following error:

error[E0283]: type annotations needed for `BackgroundProcessorConfigBuilder<'_, ..., ..., ..., ..., ..., ..., ..., ..., ..., ..., ..., ..., ..., ..., ..., ..., _, ..., ..., ..., ..., ..., ...>`
    --> lightning-background-processor/src/lib.rs:2937:7
     |
2937 |         let mut builder = BackgroundProcessorConfigBuilder::new(
     |             ^^^^^^^^^^^   -------------------------------- type must be known at this point
     |
     = note: the full type name has been written to '/home/tnull/workspace/rust-lightning/target/debug/deps/lightning_background_processor-4ef49ba2fa37c38a.long-type-17867618020029664474.txt'
     = note: cannot satisfy `_: Deref`
note: required by a bound in `BackgroundProcessorConfigBuilder`
    --> lightning-background-processor/src/lib.rs:1660:16
     |
1639 | pub struct BackgroundProcessorConfigBuilder<
     |            -------------------------------- required by a bound in this struct
...
1660 |     LM: 'static + Deref + Send,
     |                   ^^^^^ required by this bound in `BackgroundProcessorConfigBuilder`
help: consider giving `builder` an explicit type, where the type for type parameter `LM` is specified
     |
2937 |         let mut builder: BackgroundProcessorConfigBuilder<'_, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, LM, _, _, _, _, _, _> = BackgroundProcessorConfigBuilder::new(
     |                        ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For more information about this error, try `rustc --explain E0283`.
error: could not compile `lightning-background-processor` (lib test) due to 1 previous error
exit 101

But the main motivation for this change in the first place is to provide users a more reasonable API that allows them to not provide all fields, no? I think this means we'd still need to provide internal dummy values, and have them only overridden with the with_ methods, as otherwise the changes in this PR just add a bunch boilerplate without fixing the actual issue we wanted to address.

Could you look into this and see whether we find a way forward here? While we do this, could we also align the GossipSync case, which already did it with a dummy value before and hence was somewhat the odd one out in the new builder API?

Sorry for discovering this only now.

Anyitechs · 2025-06-23T14:01:08Z

But the main motivation for this change in the first place is to provide users a more reasonable API that allows them to not provide all fields, no? I think this means we'd still need to provide internal dummy values, and have them only overridden with the with_ methods, as otherwise the changes in this PR just add a bunch boilerplate without fixing the actual issue we wanted to address.

Could you look into this and see whether we find a way forward here? While we do this, could we also align the GossipSync case, which already did it with a dummy value before and hence was somewhat the odd one out in the new builder API?

Thank you for catching this. I'm working on a fix already.

joostjager · 2025-06-23T15:12:00Z

If we still need dummy implementations for everything, I'd feel more strongly than before about just dropping the builder.

tnull · 2025-06-24T07:53:10Z

If we still need dummy implementations for everything, I'd feel more strongly than before about just dropping the builder.

Hmm, I imagine the big difference would be that they'd still be completely internal and hidden from the API. I.e., the user can just use the builder as expected, without having to know/looking up all the parameters and learning how to construct a dummy value for each of them. Rather, if they are necessary at all, the builder would just use them internally, until the user explicitly overrides them.

joostjager · 2025-06-24T08:02:47Z

I don't think it is worth all the extra code and duplication. Especially because this is a single high-level call and not something that is used everywhere.

ldk-reviews-bot · 2025-06-25T00:02:02Z

🔔 2nd Reminder

Hey @joostjager! 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-06-28T00:01:08Z

🔔 3rd Reminder

Hey @joostjager! 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-06-30T00:01:58Z

🔔 4th Reminder

Hey @joostjager! 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.

tnull · 2025-07-11T10:23:16Z

@Anyitechs Any news here? Do you still intend to finish this PR?

Anyitechs · 2025-07-11T16:31:54Z

@Anyitechs Any news here? Do you still intend to finish this PR?

Yes, please pardon the delay. I'll be moving things forward on this PR this weekend, and should have an update by next week.

Anyitechs · 2025-08-14T01:09:39Z

Closing this PR as attempts to fix the issue using the builder method and other options didn't fully work (see this).

Attempted to do a dynamic dispatch but some of the traits used by the optional components, e.g WriteableScore<'a> and LockableScore<'a> for the scorer component cannot be made object-safe as it is.

Another attempted option was to use a No-operation implementation for the traits so it can be used as defaults (or dummy value) when the user doesn't provide the optional fields. But the approach is too verbose because of the associated types on the traits that goes in deep and require the trait items are also implemented.

For example, having a noop implementation for the ALiquidityManager so it can act as the dummy/default implementation when the user doesn't provide a LM field, will look similar to what I have on this github gist. Similar approach will be followed for the traits of the other optional components, making it less maintainable.

Also, I explored the typestate/state machine builder pattern, and while being verbose and complex, it still didn't work as it requires a concrete type during state transitions.

I'm happy to get back to this if there's another way to go around this issue to provide users a more reasonable API that allows them to not provide all fields.

tnull self-requested a review March 28, 2025 08:11

tnull reviewed Mar 28, 2025

View reviewed changes

Anyitechs marked this pull request as ready for review April 9, 2025 17:11

ldk-reviews-bot requested a review from wpaulino April 9, 2025 17:12

Anyitechs requested review from dunxen and tnull April 9, 2025 17:12

tnull removed the request for review from wpaulino April 9, 2025 17:17

tnull reviewed Apr 10, 2025

View reviewed changes

Anyitechs force-pushed the background-processor-builder branch from b967d87 to cb7ed79 Compare April 16, 2025 11:47

dunxen reviewed Apr 16, 2025

View reviewed changes

tnull reviewed Apr 17, 2025

View reviewed changes

Anyitechs force-pushed the background-processor-builder branch from e862860 to 7e707a9 Compare April 18, 2025 13:31

tnull mentioned this pull request Apr 23, 2025

lightning-liquidity: Introduce EventQueue notifier and wake BP for message processing #3509

Merged

tnull reviewed Apr 24, 2025

View reviewed changes

tnull reviewed Jun 16, 2025

View reviewed changes

joostjager reviewed Jun 16, 2025

View reviewed changes

Anyitechs added 2 commits June 20, 2025 18:10

feat(background-processor): add BackgroundProcessorBuilder for option…

3ffd2b4

…al components

introduce BackgroundProcessorConfigAsyncBuilder for `process_events…

e2a626d

…_async`

Anyitechs force-pushed the background-processor-builder branch 2 times, most recently from be1bdcf to b86b834 Compare June 20, 2025 17:44

graphite-app bot reviewed Jun 20, 2025

View reviewed changes

lightning-background-processor/src/lib.rs Outdated Show resolved Hide resolved

fixup! update docs on start and config objects

2b83ad2

Anyitechs force-pushed the background-processor-builder branch from b86b834 to 2b83ad2 Compare June 20, 2025 17:59

Anyitechs requested review from joostjager and tnull June 20, 2025 18:21

tnull reviewed Jun 23, 2025

View reviewed changes

joostjager removed their request for review June 30, 2025 07:58

tnull mentioned this pull request Jul 11, 2025

Async background persistence #3905

Merged

Anyitechs closed this Aug 14, 2025

tnull mentioned this pull request Sep 22, 2025

Add concrete NO_* consts to avoid users having to specify types #4100

Merged

feat(background-processor): introduce builder for BackgroundProcessor and process_events_async #3688

feat(background-processor): introduce builder for BackgroundProcessor and process_events_async #3688

Uh oh!

Conversation

Anyitechs commented Mar 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

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

Uh oh!

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!

Choose a reason for hiding this comment

Uh oh!

ldk-reviews-bot commented Mar 28, 2025

Uh oh!

Anyitechs commented Mar 28, 2025

Uh oh!

tnull commented Mar 28, 2025

Uh oh!

Anyitechs commented Mar 28, 2025

Uh oh!

tnull commented Mar 28, 2025

Uh oh!

Anyitechs commented Mar 28, 2025

Uh oh!

Anyitechs commented Apr 9, 2025

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 commented Apr 10, 2025

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!

Anyitechs commented Apr 10, 2025

Uh oh!

ldk-reviews-bot commented Apr 12, 2025

Uh oh!

ldk-reviews-bot commented Apr 14, 2025

Uh oh!

Anyitechs commented Apr 14, 2025

Uh oh!

ldk-reviews-bot commented Apr 16, 2025

Uh oh!

dunxen left a comment

Choose a reason for hiding this comment

Uh oh!

Anyitechs commented Apr 16, 2025

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

feat(background-processor): introduce builder for `BackgroundProcessor` and `process_events_async` #3688

feat(background-processor): introduce builder for `BackgroundProcessor` and `process_events_async` #3688

Anyitechs commented Mar 28, 2025 •

edited

Loading

ldk-reviews-bot commented Mar 28, 2025 •

edited

Loading

joostjager Jun 16, 2025 •

edited

Loading

joostjager Jun 18, 2025 •

edited

Loading