From cd33a06136ee115bc61993260a9f9429fd642858 Mon Sep 17 00:00:00 2001 From: Seto Elkahfi <1797197+setoelkahfi@users.noreply.github.com> Date: Sun, 11 Oct 2026 20:26:30 +0200 Subject: [PATCH] docs(aso): clarify list_builds limit=200 is page size, not a cap The `limit=200` on the builds collection reads like a ceiling, but `list_all` follows Apple's `links.next` cursor until the collection is exhausted. Spell out that 200 is the largest page ASC allows (fewer round-trips), not the number of builds returned, so callers don't treat the vector length as "the 200 most recent builds." Co-Authored-By: siGit Code v1.6.7-acp --- crates/aso/src/build.rs | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/crates/aso/src/build.rs b/crates/aso/src/build.rs index 5f392a8..3f78b4e 100644 --- a/crates/aso/src/build.rs +++ b/crates/aso/src/build.rs @@ -97,6 +97,13 @@ pub trait BuildsApi { /// Pass `&BuildFilter::default()` for every build, or set fields to /// narrow by build number, pre-release (marketing) version, or /// processing state. + /// + /// The `limit=200` this sends is a *page size*, not a ceiling on the + /// result: [`Client::list_all`] follows Apple's `links.next` cursor until + /// the collection is exhausted, so an app with more than 200 builds still + /// returns all of them — 200 is just the largest page ASC allows for this + /// collection, which keeps the round-trip count down. Do not read the + /// vector's length as "the 200 most recent builds." async fn list_builds(&self, app_id: &str, filter: &BuildFilter) -> Result>; /// `GET /v1/builds/{id}` — a single build by its App Store Connect id.