fix: make ReadBuffer.clear() unpoison the buffer

ReadBuffer.clear() and ReadBuffer.reset() were silently asymmetric:
reset() (added alongside the poison concept in issue 026) cleared
_poisoned, while clear() (which predated the poison concept) did not.
A caller reaching for clear() as "the simpler recovery primitive"
got a half-fresh buffer: bytes gone, offset reset, but still
raising ProtocolError from the poison gate on the next operation.

Make clear() a thin alias for reset(). Behaviourally equivalent for
a clean buffer, correct for a poisoned one. This is also a
prerequisite for gating the ReadBuffer public API on the poison
flag (issue 038), since otherwise any caller who used clear() as
their recovery path would be locked out.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: antoineleclair

src/dqlitewire/buffer.py

@@ -282,7 +282,14 @@ def is_skipping(self) -> bool:
         return self._skip_remaining > 0
 
     def clear(self) -> None:
-        """Clear the buffer."""
-        self._data.clear()
-        self._pos = 0
-        self._skip_remaining = 0
+        """Clear buffer state and un-poison.
+
+        Equivalent to ``reset()``. Kept as a convenience alias because
+        ``clear()`` predates the poison concept (issue 026) and was
+        briefly inconsistent with ``reset()`` — it used to leave the
+        ``_poisoned`` flag intact, which meant a caller who reached
+        for ``clear()`` as a recovery primitive got a half-fresh
+        buffer that still raised ``ProtocolError`` on the next
+        operation (issue 040).
+        """
+        self.reset()

tests/test_buffer.py

@@ -187,6 +187,35 @@ def test_clear(self) -> None:
         buf.clear()
         assert buf.available() == 0
 
+    def test_clear_also_unpoisons(self) -> None:
+        """Regression for issue 040.
+
+        ``ReadBuffer`` has two very similar methods: ``clear()`` and
+        ``reset()``. ``reset()`` was introduced by issue 026 as the
+        recovery primitive for the poison flag. ``clear()`` predates
+        the poison concept and was never updated — it still resets
+        ``_data``/``_pos``/``_skip_remaining`` but leaves
+        ``_poisoned`` intact. A caller who reaches for ``clear()``
+        expecting it to be "the simpler recovery method" gets a
+        half-fresh buffer that still raises ``ProtocolError`` on the
+        next operation. The asymmetry is invisible at the API level
+        (one-line docstrings, similar names), so the only safe
+        behaviour is for both methods to unpoison.
+        """
+        from dqlitewire.exceptions import DecodeError
+
+        buf = ReadBuffer()
+        buf.feed(b"\x00" * 16)
+        buf.poison(DecodeError("boom"))
+        assert buf.is_poisoned
+
+        buf.clear()
+
+        assert not buf.is_poisoned
+        # And the buffer must be usable after the clear+reconnect.
+        buf.feed(b"\x01\x00\x00\x00\x00\x00\x00\x00")
+        assert buf.available() == 8
+
     def test_has_message_is_total_on_oversized(self) -> None:
         """has_message() must not raise — oversized headers surface at consume time.