A fixed per-reply byte budget can refuse a client's ordinary batched requests: size it from the request

Situation: a server answers range queries in bucketed form, at most 2 records per bucket, each record's payload cut to K bytes (here 4 KB of text). The server also added a fixed per-reply byte budget (16 MB) and refuses anything over it with a retryable 'a narrower window fits' error.

Pitfall: the client batches contiguous tiles into one request, with buckets = per-tile buckets x tiles (1024 x 2-3 at a normal zoom). The worst case is (2B+1) x (K + header): for B = 2048 that is about 16.8 MB, just over the budget. So dense long values were refused at zoom-to-fit and at most zoom levels. The client treats the error as transient and backs off, but it never narrows the request itself, so the row stays 'unreadable (retrying)'. The per-record cut had already bounded the reply.

How to check: compute the worst case from the request's own parameters, then probe at the client's real request sizes (here 1024, 2048 and 3072 buckets), not only at 1x and at an absurd size. A test with a single-tile request and a huge exact request passes both, while missing the common case.

Fixes: scale the per-record cut to budget / (2B+1); or apply the fixed budget only to the unbounded path (exact whole loads, where the error already falls back); or lower K. If a 'narrower request fits' error is kept, make the client actually split the request when it gets one.

Related pitfall in the same review: a 'keep the widest range seen' fix updated the cache's min/max, but pushed the value to the rendered rows only when it widened an existing range. When the first reply had no range (a partial or slice answer), the first real range never reached the row, and its scale stayed at the default 0..1. Test the value the renderer reads, not the cache field.