A municipal 311 intake tool walks DNA Center client pages and builds one list for the night’s report. Inside the loop the code does results = page.items on every iteration. What construction mistake does that introduce?
Select an answer to reveal the explanation.
Short Explanation
Picture packing boxes onto a truck, then tossing the whole load and keeping only the last box each stop. Assigning results = page.items overwrites everything before the final window. Append or stream each slice instead.
Full Explanation
When a municipal 311 tool walks DNA Center client pages into one nightly list, each page must be accumulated into the report’s working set. Assignment of the form results = page.items replaces the entire collection with only that window’s items, so earlier pages vanish and the night’s client inventory silently undercounts. Correct construction appends or extends each page into a growing structure, or streams and processes each slice before discarding it, so every DNA Center window contributes once.
Duplicating Authorization headers on each request is an unrelated client mistake and is not what a reassignment of results causes. Forcing the API to emit a total-count field misstates DNA Center’s paging contract and does not explain why earlier pages disappear from memory. Converting the REST walk into a WebSocket subscription that never closes invents a transport change the assignment bug does not perform.
Exam caveat: overwrite versus accumulate is a classic pagination construction trap—correct next or cursor handling still fails the civic report if you keep only the last page. Operational check: after three known-length pages, assert len(results) equals the sum of page lengths (or that each page was processed once), not merely the length of the final page.items slice, before publishing the 311 nightly file.