You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The client layer (dqliteclient) already plumbs the inbound-frame-size
cap through connect() / create_pool() / DqliteConnection /
DqliteProtocol. The dbapi layer was the missing piece — operators
configuring the kwarg through dqlitedbapi.connect() or aio.connect()
had no path to forward it.
Thread max_message_size through:
- dqlitedbapi.connect() / aio.connect() / aio.aconnect() signatures
+ forward to the underlying Connection / AsyncConnection.
- Connection.__init__ / AsyncConnection.__init__ accept and store on
self._max_message_size (None = wire-default 64 MiB).
- _build_and_connect / _resolve_leader / _get_resolve_leader_cluster
accept the kwarg with default None so existing callers continue
to compile; the cache key inside _get_resolve_leader_cluster
includes max_message_size so the dbapi connect() variant produces
independent cache entries.
- The ClusterClient construction inside _get_resolve_leader_cluster
does NOT forward max_message_size — ClusterClient's constructor
lacks the kwarg today (only its per-call connect() method takes
it). The leader-probe RPC returns a small LeaderResponse bounded
well below the wire-default cap; the operator's larger cap matters
only for the eventual DqliteConnection data session, which IS
built with max_message_size at the _build_and_connect call site.
The wire layer is the single source of truth for validation
(positive int, non-bool); the dbapi forward passes the value through
verbatim, mirroring the reviewer's "one place to maintain the
contract" guidance.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
0 commit comments