Uh oh!
There was an error while loading. Please reload this page.
Account for LiquidityManager persistence - #650
Conversation
👋 I see @jkczyz was un-assigned. |
dad5932 to
53d4f0aComparetnull
commented
Oct 7, 2025
We decided to make the |
We recently implemented persistence for the `lightning-liquidity` service state. Here we make corresponding changes in LDK Node to have our service state persisted.
53d4f0a to
a404a94Comparetnull
commented
Oct 8, 2025
Ready for review now that #633 landed. |
| liquidity_client_config, | ||
| ) | ||
| .await | ||
| .map_err(|_| BuildError::ReadFailed)?, |
There was a problem hiding this comment.
Reading data in new, isn't that an undesirable pattern?
There was a problem hiding this comment.
Maybe, yes. We did it over at lightningdevkit/rust-lightning#4059 since the individual service states are persisted under different locations and the LiquidityManager is the singular interface on which you can decide which services to enable. So allowing an API that allows to enable some services but not reading all the service states seemed complicated and error-prone (i.e., worse than reading them all in new.
| let liquidity_source = Arc::new(liquidity_source_builder.build()); | ||
| let liquidity_source = runtime | ||
| .block_on(async move { liquidity_source_builder.build().await.map(Arc::new) })?; |
There was a problem hiding this comment.
Assuming this is temporary until async building?
There was a problem hiding this comment.
Yes, we'll remove this when we move building to Node::start and make it async.
Uh oh!
There was an error while loading. Please reload this page.
Based on #633.
We recently implemented persistence for the
lightning-liquidityservicestate. Here we make corresponding changes in LDK Node to have our
service state persisted.