A transit-ops dashboard asks the Meraki API for limit=100 client records but the server returns 40 and a next pointer. The offset math still adds 100 for the following request. What should drive the next-request step?
Select an answer to reveal the explanation.
Short Explanation
You ordered a full carton; the warehouse shipped a half-carton and a note saying “more here.” Step by what actually arrived (or follow their next note), not by the carton size you wished for. Otherwise offsets skip or overlap.
Full Explanation
When the Meraki API returns fewer client records than the transit-ops dashboard requested yet still provides a next pointer, the server—not the client’s hoped-for limit—defines how to step. Drive the following request from the actual returned length or, preferably, from the next or cursor the platform published. Blindly adding the requested limit of 100 when only 40 arrived skips ahead in offset space and drops or overlaps clients in the civic report.
Always adding the client’s requested limit ignores short pages and next pointers, producing systematic gaps. Multiplying the requested limit whenever the page is short invents an aggressive stride that widens those skips. Restarting at offset 0 after every short page re-fetches the head of the collection forever and never progresses the dashboard’s walk.
Exam caveat: short-but-continued pages are normal under server-side caps; termination is absence of next (or an empty page per that API’s contract), not “returned count equals requested limit.” Operational check: on a short page with next present, assert the next request uses the server cursor or offset += len(items), then spot-check that client ids from the first window still appear exactly once in the aggregated list.