mirror of
https://github.com/storytold/figcraft.git
synced 2026-10-29 12:56:47 -06:00
Hamza
3df5673627
Two things the limit got wrong, both reported by CodeRabbit on #915. maxBytes was compared with the escaped text block alone, but what goes on the wire is that block inside a content object, inside the JSON-RPC result, with the request id and the newline the transport writes: a block measured at exactly maxBytes left as a larger message than the caller said it could read. A kilobyte of the caller's figure is now kept for that wrapping. About ninety bytes of it is fixed and the rest is the request id, so the figure holds for any id up to roughly 900 bytes -- every id in practice, a number or a UUID. Sizing the real envelope here would mean handing the transport's request id to every tool, and the assumption is written down instead, in the schema and at the constant. A depth: 0 request over the limit returned early, so the one response that cannot be made any smaller was the one sent without the truncated marker -- while a bisection that walked down to depth 0 sent the same tree with it. Depth 0 now takes the same path as the bisection: the tree goes out, over the limit, with the marker saying so. Without the first fix the test reports a limit at the exact size of the tree as no truncation; without the second the depth-0 marker is absent (left: (None, None), right: (Some(0), Some(0))).