Raise _MAX_COLUMN_COUNT to SQLite's documented default

The C server emits sqlite3_column_count(stmt) as uint64 without
cap (query.c:111-120); STMT__MAX_COLUMNS in stmt.c:10 is defined
but never referenced anywhere in the C tree, so the Python-side
cap is defence-in-depth against pathological emissions rather than
a wire-protocol mirror. SQLite's compile-time SQLITE_MAX_COLUMN
default is 2000; analytical / feature-store wide-table SELECTs
legitimately cross the prior 255 cap. Raise to 2000 so legitimate
frames decode while still rejecting absurd peer emissions. The
per-name cap (_MAX_COLUMN_NAME_SIZE = 4096) and frame-envelope
cap already bound memory growth.

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

Author: antoineleclair

src/dqlitewire/messages/responses.py

@@ -58,19 +58,26 @@
 
 logger = logging.getLogger(__name__)
 
-# Defense-in-depth upper bounds for count fields in response messages.
-# Tightened to dqlite's actual emission ceiling: the C server's
-# ``stmt.c:10`` defines ``STMT__MAX_COLUMNS = (1 << 8) - 1 = 255``
-# with the explicit comment "fits in one byte". Any column count
-# above 255 from a real cluster is provably malformed.
+# Defense-in-depth upper bound on the column count in
+# ``RowsResponse``. The C server's ``query.c:111-120`` calls
+# ``sqlite3_column_count(stmt)`` and encodes the result as
+# ``uint64`` WITHOUT a wire-protocol cap; the
+# ``STMT__MAX_COLUMNS`` macro in ``stmt.c:10`` is defined but
+# never referenced (verified by grep across the canonical/dqlite
+# C tree). The Python-side cap is therefore defence-in-depth
+# against pathological peer emissions, not a wire-protocol mirror.
 #
-# SQLite itself documents ``SQLITE_MAX_COLUMN = 32767`` as the
-# absolute build-time maximum (https://www.sqlite.org/limits.html),
-# but dqlite never approaches it. Capping at 255 closes a
-# defence-in-depth amplification window: a hostile peer emitting
-# ``column_count = 32766`` would force ~32k empty-string
-# allocations before per-string size caps kick in.
-_MAX_COLUMN_COUNT: Final[int] = 255
+# SQLite's compile-time ``SQLITE_MAX_COLUMN`` default is 2000
+# (raisable to 32767 via build flag); a wide-table SELECT against
+# an analytics / feature-store schema legitimately crosses the
+# prior 255 cap. Cap at SQLite's documented default so legitimate
+# frames decode while still rejecting absurd peer emissions. The
+# per-name cap (``_MAX_COLUMN_NAME_SIZE = 4096``) and the frame-
+# envelope cap (default 64 MiB) already bound memory growth from
+# the N × name allocation.
+#
+# Reference: https://www.sqlite.org/limits.html#max_column.
+_MAX_COLUMN_COUNT: Final[int] = 2000
 _MAX_FILE_COUNT: Final[int] = 100
 # Defence-in-depth cap on the ServersResponse node count. Upstream
 # (C ``gateway.c::handle_cluster`` reads ``response.n =

tests/test_constants.py

@@ -465,13 +465,16 @@ def test_max_param_count_matches_sqlite_max_variable_number(self) -> None:
         # intermediate allocations.
         assert _MAX_PARAM_COUNT == 32_766
 
-    def test_max_column_count_matches_dqlite_stmt_max(self) -> None:
+    def test_max_column_count_matches_sqlite_default(self) -> None:
         from dqlitewire.messages.responses import _MAX_COLUMN_COUNT
 
-        # The C server's ``STMT__MAX_COLUMNS = (1 << 8) - 1 = 255``
-        # is the actual emission ceiling. Any column count above 255
-        # from a real dqlite cluster is provably malformed.
-        assert _MAX_COLUMN_COUNT == 255
+        # SQLite's compile-time ``SQLITE_MAX_COLUMN`` default is 2000.
+        # The C server's ``query.c:111-120`` emits the column count
+        # as ``uint64`` without cap; ``STMT__MAX_COLUMNS`` in
+        # ``stmt.c:10`` is defined but never referenced, so the
+        # Python cap is defence-in-depth rather than a wire-protocol
+        # mirror.
+        assert _MAX_COLUMN_COUNT == 2000
 
     def test_max_file_count_is_one_hundred(self) -> None:
         from dqlitewire.messages.responses import _MAX_FILE_COUNT

tests/test_max_column_count_cap.py

@@ -1,10 +1,19 @@
-"""``_MAX_COLUMN_COUNT`` is set to dqlite's actual emission ceiling
-(255) so a hostile peer cannot inflate intermediate Python-side
-allocations by claiming a higher column count than the C server
-ever produces.
+"""``_MAX_COLUMN_COUNT`` is set to SQLite's documented column limit
+(``SQLITE_MAX_COLUMN = 2000``) so legitimate wide-table SELECT
+results decode while still rejecting absurd peer emissions.
 
-The C server's ``stmt.c:10`` defines
-``STMT__MAX_COLUMNS = (1 << 8) - 1 = 255``.
+The C server emits ``sqlite3_column_count(stmt)`` as a uint64
+without cap (``query.c:111-120``); ``stmt.c:10``'s
+``STMT__MAX_COLUMNS = (1 << 8) - 1 = 255`` macro is defined but
+never referenced. SQLite's compile-time default is 2000 (raisable
+to 32767 via ``SQLITE_MAX_COLUMN`` build flag); a wide-table
+SELECT against an analytics / feature-store schema legitimately
+crosses 255 columns.
+
+The per-name cap (``_MAX_COLUMN_NAME_SIZE = 4096``) and the frame-
+envelope cap (default 64 MiB) already bound memory growth from the
+N × name allocation; this cap is defence-in-depth against
+pathological peer emissions, not the load-bearing memory bound.
 """
 
 import pytest
@@ -18,33 +27,51 @@
 from dqlitewire.types import encode_uint64
 
 
-def test_max_column_count_pinned_to_255() -> None:
-    assert _MAX_COLUMN_COUNT == 255
+def test_max_column_count_pinned_to_sqlite_default() -> None:
+    """SQLite's documented default ``SQLITE_MAX_COLUMN`` is 2000."""
+    assert _MAX_COLUMN_COUNT == 2000
 
 
-def test_rows_response_rejects_count_above_255() -> None:
-    body = encode_uint64(256)
+def test_rows_response_rejects_count_above_cap() -> None:
+    body = encode_uint64(_MAX_COLUMN_COUNT + 1)
     with pytest.raises(DecodeError, match="(?i)column count"):
         RowsResponse.decode_body(body)
 
 
-def test_rows_response_accepts_count_at_255() -> None:
-    """A 255-column rows response is well-formed and must not be
+def test_rows_response_accepts_count_at_cap() -> None:
+    """A 2000-column rows response is well-formed and must not be
     rejected by the cap; it fails the body-size check instead
     because we only sent the count, not the column names."""
-    body = encode_uint64(255)
+    body = encode_uint64(_MAX_COLUMN_COUNT)
+    with pytest.raises(DecodeError, match="exceeds maximum possible"):
+        RowsResponse.decode_body(body)
+
+
+def test_rows_response_accepts_count_above_old_255_cap() -> None:
+    """Pin the regression-vs-old-cap shape: a 1500-column emission
+    (legitimate wide table, above the prior 255 cap but below the
+    new 2000 cap) must NOT trip the column-count cap. It still
+    fails the body-size check below because we only sent the count,
+    not the per-column name payload."""
+    body = encode_uint64(1500)
     with pytest.raises(DecodeError, match="exceeds maximum possible"):
         RowsResponse.decode_body(body)
 
 
-def test_servers_response_rejects_count_above_255() -> None:
-    """``ServersResponse`` shares the same column-count cap path
-    via ``_MAX_NODE_COUNT`` (separate cap) but uses
-    ``_MAX_COLUMN_COUNT``-style protection on its own count field."""
-    # ``ServersResponse`` uses ``_MAX_NODE_COUNT = 10_000``; the
-    # column cap does not apply directly. Pinning here is a sanity
-    # check that the cap constant was not accidentally inlined into
-    # an unrelated field.
+def test_rows_response_rejects_absurd_count() -> None:
+    """A pathological emission (``column_count = 2^31``) must still
+    be rejected so a hostile peer cannot inflate Python-side
+    allocations."""
+    body = encode_uint64(1 << 31)
+    with pytest.raises(DecodeError, match="(?i)column count"):
+        RowsResponse.decode_body(body)
+
+
+def test_servers_response_uses_separate_cap() -> None:
+    """``ServersResponse`` uses ``_MAX_NODE_COUNT = 10_000``; the
+    column cap does not apply. Pinning here is a sanity check that
+    the cap constant was not accidentally inlined into an unrelated
+    field."""
     assert _MAX_COLUMN_COUNT < 10_000