lntransport: wrap connection errors in send_bytes_and_drain
What the developer wrote
Authored by SomberNight
lntransport: wrap connection errors in send_bytes_and_drain
LightningPeerConnectionClosed is handled in Peer.handle_disconnect.
```
162.39 | E | lnpeer.Peer.[LNGossip, 02ab5336d0-d8be58cb] | Exception in main_loop: ConnectionResetError('Connection lost')
Traceback (most recent call last):
File "/home/user/wspace/electrum/electrum/util.py", line 1218, in wrapper
return await func(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/user/wspace/electrum/electrum/lnpeer.py", line 544, in wrapper_func
return await func(self, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/user/wspace/electrum/electrum/lnpeer.py", line 558, in main_loop
async with self.taskgroup as group:
^^^^^^^^^^^^^^
File "/home/user/wspace/aiorpcX/aiorpcx/curio.py", line 304, in __aexit__
await self.join()
File "/home/user/wspace/electrum/electrum/util.py", line 1423, in join
task.result()
~~~~~~~~~~~^^
File "/home/user/wspace/electrum/electrum/lnpeer.py", line 897, in _message_loop
await self._process_message(msg)
File "/home/user/wspace/electrum/electrum/lnpeer.py", line 277, in _process_message
await f(*args)
File "/home/user/wspace/electrum/electrum/lnpeer.py", line 389, in on_ping
await self.transport.send_bytes_and_drain(raw_msg)
File "/home/user/wspace/electrum/electrum/lntransport.py", line 238, in send_bytes_and_drain
await self.writer.drain()
File "/usr/lib/python3.13/asyncio/streams.py", line 386, in drain
await self._protocol._drain_helper()
File "/usr/lib/python3.13/asyncio/streams.py", line 166, in _drain_helper
raise ConnectionResetError('Connection lost')
ConnectionResetError: Connection lost
```
What changed, and why it matters
This commit fixes a minor error-handling bug in Electrum's Lightning network code. When the program tried to send data over a peer connection that had already dropped, a low-level 'Connection lost' error was escaping instead of being converted into the expected 'peer disconnected' exception. The patch wraps the connection error so the rest of the program handles the disconnect cleanly. There is no indication this is a security vulnerability or that it can be exploited by an attacker.
Treat as a routine robustness fix. No urgent security action required. Users running Lightning in Electrum may benefit from the cleaner disconnect handling, so normal update cadence is sufficient.
Security signals we found
Defensive exception normalization in network I/O path
No untrusted input parsing or memory-unsafe operation introduced
No authentication, authorization, or cryptographic change
No vendor disclosure of security relevance
Evidence from the diff
In electrum/lntransport.py, send_bytes_and_drain() now catches ConnectionError from writer.drain() and re-raises it as LightningPeerConnectionClosed. This ensures that lnpeer.Peer.handle_disconnect’s exception-handling path is taken when the underlying TCP connection is reset, rather than propagating an unhandled ConnectionResetError through the task group. The change is defensive and improves robustness of Lightning peer disconnection handling.
Changed components
electrum/lntransport.pyLNTransportBase.send_bytes_and_drain()Lightning peer connection teardown pathInspect captured patch +4 / −1
diff --git a/electrum/lntransport.py b/electrum/lntransport.py
index 8f242ea..580a28c 100644
--- a/electrum/lntransport.py
+++ b/electrum/lntransport.py
@@ -235,7 +235,10 @@ class LNTransportBase:
"""Should be used when possible (in async scope), to avoid memory exhaustion."""
async with self.drain_write_lock:
self.send_bytes(msg)
- await self.writer.drain()
+ try:
+ await self.writer.drain()
+ except ConnectionError as e:
+ raise LightningPeerConnectionClosed() from e
async def read_messages(self):
buffer = bytearray()
Why this scored 25/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.