While paging Firepower FDM network objects for a municipal firewall audit, the consumer receives HTTP 429 mid-walk. After honoring Retry-After, what should it do with the pagination cursor?
Select an answer to reveal the explanation.
Short Explanation
You were on chapter twelve when the librarian said “wait five minutes.” After the wait, reopen chapter twelve—don’t start the book over (duplicates) or toss the rest. Resume the same cursor after the pause.
Full Explanation
Mid-walk HTTP 429 while paging Firepower FDM network objects means the municipal audit consumer must slow down, not rewind or abandon. After honoring Retry-After or equivalent rate-limit guidance, resume from the same next URL or offset already held. The firewall object walk then continues without duplicate early pages and without silently truncating the audited set.
Restarting at page one after every 429 re-downloads completed windows, wastes quota, and risks duplicate processing of the same objects. Marking the audit complete on a partial set hides missing network objects behind a green status. Jumping the offset by a large constant to skip the limited window invents holes in the collection and may still collide with the same limiter on the next burst. Preserve any in-memory partial aggregation across the pause so resumed pages append cleanly. If Retry-After is missing, apply a bounded exponential backoff still keyed to the same cursor, and surface a municipal audit warning only when retries are exhausted—not on the first 429.
Exam caveat: rate-limit handling is pause-and-resume with cursor preservation; it is not a signal that pagination semantics changed or that the audit may stop early. Operational check: log the cursor before the 429, sleep per Retry-After, replay the same next or offset, and verify object ids remain contiguous without a reset to page one in request traces.