Summary
/pool_info and /drep_info reject a request body somewhere between 4.5 KB and 6 KB with a 413, but the limit is not documented and the endpoints do not advertise a maximum batch size. Consumers find it by hitting it.
Reproduction
Live mainnet, /pool_info, varying the number of ids in _pool_bech32_ids:
75 ids (4,522 byte body) -> HTTP 200
100 ids (6,022 byte body) -> HTTP 413
Same shape on preprod. /drep_info behaves the same way, which is unsurprising given DRep ids are about the same size as pool ids.
Why it is worth documenting
A pool id is a fixed 56-character bech32 string, so a caller can reason perfectly well about how many fit, if they know the cap. Without it, the natural thing to do is batch by a round number like 100, which is exactly where it breaks. There is nothing in the spec or the response that hints at a limit until you get the 413, and the 413 does not say what the limit is.
It bites hardest on the endpoints where batching is the whole point. We page pool_list and then hydrate the page with pool_info, and a 100-pool page is a perfectly reasonable thing to want.
What would help, in rough order of usefulness
- Document the maximum request body size (and, ideally, the resulting maximum ids per call) for the batch endpoints in the API spec.
- Have the 413 say what the limit is, so a caller can adapt rather than bisect.
- If the cap is arbitrary rather than load-driven, consider raising it: 6 KB is only about 100 pool ids, which is a small batch for an endpoint whose purpose is batching.
Workaround
We chunk at 50 ids per call, which leaves headroom. That is fine, it just took an afternoon of bisecting to land on, and every other consumer will have to do the same.
Summary
/pool_infoand/drep_inforeject a request body somewhere between 4.5 KB and 6 KB with a413, but the limit is not documented and the endpoints do not advertise a maximum batch size. Consumers find it by hitting it.Reproduction
Live mainnet,
/pool_info, varying the number of ids in_pool_bech32_ids:Same shape on preprod.
/drep_infobehaves the same way, which is unsurprising given DRep ids are about the same size as pool ids.Why it is worth documenting
A pool id is a fixed 56-character bech32 string, so a caller can reason perfectly well about how many fit, if they know the cap. Without it, the natural thing to do is batch by a round number like 100, which is exactly where it breaks. There is nothing in the spec or the response that hints at a limit until you get the 413, and the 413 does not say what the limit is.
It bites hardest on the endpoints where batching is the whole point. We page
pool_listand then hydrate the page withpool_info, and a 100-pool page is a perfectly reasonable thing to want.What would help, in rough order of usefulness
Workaround
We chunk at 50 ids per call, which leaves headroom. That is fine, it just took an afternoon of bisecting to land on, and every other consumer will have to do the same.