Add APIs to prune completed state for LSPS1/LSPS2/LSPS5#4526
Add APIs to prune completed state for LSPS1/LSPS2/LSPS5#4526f3r10 wants to merge 1 commit intolightningdevkit:mainfrom
Conversation
`LSPS1ServiceHandler` accumulates `ChannelOrder` records indefinitely. `CompletedAndChannelOpened` orders were never pruned automatically, and `FailedAndRefunded` orders were only pruned once all payment invoices in them had expired — which can be days away. Add `LSPS1ServiceHandler::prune_order` (and a sync wrapper on `LSPS1ServiceHandlerSync`) that lets the LSP operator explicitly remove any order that has reached a terminal state. The call persists the change to the KVStore before returning. Non-terminal orders (`ExpectingPayment`, `OrderPaid`) are rejected with the new `PeerStateError::OrderNotPrunable` variant so that in-progress orders cannot be silently discarded.
|
👋 Hi! I see this is a draft PR. |
| /// | ||
| /// Returns an [`APIError::APIMisuseError`] if the counterparty has no state, the order is | ||
| /// unknown, or the order is in a non-terminal state. | ||
| pub async fn prune_order( |
There was a problem hiding this comment.
Hmm, is the right API to require downstream code list the specific orders to prune or should we have some kind of "prune all failed orders older than X" API? @tnull wdyt?
There was a problem hiding this comment.
You are right @TheBlueMatt, it would be much better something like this:
handler.prune_orders(client_id, Duration::from_secs(30 * 24 * 3600)).await?;
I am going to update that part. Thanks for the early review
There was a problem hiding this comment.
Yeah, I agree, allowing to prune older entries in an interval is great. At some point we still might want to expose the LSPS{1,2} service state via the API, at which point allowing to drop specific orders would make sense, but not sure if that's not better done in a dedicated follow-up.
There was a problem hiding this comment.
I think it would be better in a follow-up when service state listing exists
No description provided.