Reject clients if request registration failed (e.g., duplicative Id)
What the developer wrote
Authored by Elias Rohrer
Reject clients if request registration failed (e.g., duplicative Id)
Signed-off-by: Elias Rohrer <dev@tnull.de>
What changed, and why it matters
This small patch fixes a messaging bug in a Lightning liquidity service. Previously, if a client sent a duplicate request ID, the server would log an error but would not tell the client that the request was rejected, leaving the client waiting for a response. Now the server sends an explicit rejection message back to the client. The main risk is a mild denial-of-service or confusion from duplicate/lingering request IDs, not theft of funds or remote code execution.
Treat as a low-severity protocol robustness fix. Review whether duplicate request IDs can be triggered by a peer intentionally to cause resource consumption or state confusion, and consider adding tests for the new rejection path. No urgent security response appears required based on the diff alone.
Security signals we found
Missing error response on duplicate request ID could leave peer state mismatched or cause client-side retry storms
Fix adds explicit protocol-level rejection (LSPS0_CLIENT_REJECTED_ERROR_CODE) instead of silently dropping the request
No evidence of memory safety issue, cryptographic flaw, or authorization bypass in the diff
Evidence from the diff
In lightning-liquidity/src/lsps1/service.rs, the error path of register_request for a duplicate request_id now constructs an LSPS1Response::CreateOrderError with LSPS0_CLIENT_REJECTED_ERROR_CODE, wraps it in an LSPS1Message::Response, and enqueues it to the counterparty_node_id via message_queue_notifier. Before this change, the same error path only logged the failure and returned a LightningError with ErrorAction::IgnoreAndLog, so the peer received no response for the duplicate request. This is a protocol-correctness fix for the LSPS1 service handler.
Changed components
lightning-liquidity/src/lsps1/service.rsLSPS1 CreateOrder request handlerInspect captured patch +7 / −0
diff --git a/lightning-liquidity/src/lsps1/service.rs b/lightning-liquidity/src/lsps1/service.rs
index 7cf0412..e776ae2 100644
--- a/lightning-liquidity/src/lsps1/service.rs
+++ b/lightning-liquidity/src/lsps1/service.rs
@@ -339,6 +339,13 @@ where
let request = LSPS1Request::CreateOrder(params.clone());
peer_state_lock.register_request(request_id.clone(), request).map_err(|e| {
let err = format!("Failed to handle request due to: {}", e);
+ let response = LSPS1Response::CreateOrderError(LSPSResponseError {
+ code: LSPS0_CLIENT_REJECTED_ERROR_CODE,
+ message: err.clone(),
+ data: None,
+ });
+ let msg = LSPS1Message::Response(request_id.clone(), response).into();
+ message_queue_notifier.enqueue(counterparty_node_id, msg);
let action = ErrorAction::IgnoreAndLog(Level::Error);
LightningError { err, action }
})?;
Why this scored 37/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.