Limits support for large query results in Consul catalog API

Goal

To retrieve large service or key/value listings from Consul without exhausting client memory or network bandwidth while preserving the ability to react to changes in real time.

Current Constraints

The HTTP API exposes blocking queries via index and wait parameters, which throttle request frequency but still return the full payload. Catalog endpoints such as /v1/catalog/services and KV endpoints like /v1/kv/<prefix>?recurse=true lack any documented limit, offset, or cursor parameters. Clients must either filter aggressively or perform client‑side pagination after the entire result set is received.

Unresolved Decision

HashiCorp’s documentation does not indicate any plan to introduce native pagination for catalog or KV queries. This leaves large datasets as a consumer‑side implementation detail and raises questions about how a future pagination feature would coexist with existing blocking query semantics.

Questions

• What technical constraints would prevent Consul from adding a limit or cursor‑based paging mechanism to catalog and KV endpoints?
• How would pagination interact with the current blocking query model that relies on index and wait?
• Is there an API‑level trade‑off between exposing pagination and maintaining the lightweight, HTTP‑only nature of Consul’s service discovery interface?