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 <noreply@sigit.si>
Seto Elkahfi committed
Oct 11, 2026 at 20:26 UTC
cd33a06136ee115bc61993260a9f9429fd642858
1 file changed
+7
crates/aso/src/build.rs
+7
@@ -97,6 +97,13 @@ pub trait BuildsApi {
97
/// Pass `&BuildFilter::default()` for every build, or set fields to
98
/// narrow by build number, pre-release (marketing) version, or
99
/// processing state.
100
+ ///
101
+ /// The `limit=200` this sends is a *page size*, not a ceiling on the
102
+ /// result: [`Client::list_all`] follows Apple's `links.next` cursor until
103
+ /// the collection is exhausted, so an app with more than 200 builds still
104
+ /// returns all of them — 200 is just the largest page ASC allows for this
105
+ /// collection, which keeps the round-trip count down. Do not read the
106
+ /// vector's length as "the 200 most recent builds."
107
async fn list_builds(&self, app_id: &str, filter: &BuildFilter) -> Result<Vec<Build>>;
108
109
/// `GET /v1/builds/{id}` — a single build by its App Store Connect id.