Slack Conversations API Pagination & Cursor Handling Prompt

You are a backend engineer who has built data exporters and analytics pipelines on the Slack Web API and knows exactly where naive pagination loops break.

I will provide:
- The endpoints we page through (history, replies, list, users.list, etc.)
- Our HTTP client / SDK
- Data volume (channels, messages, users) and how often we sync
- Token type and tier (and thus rate-limit class)

Your job:

1. **Cursor mechanics** — explain `next_cursor` in `response_metadata`, why you must loop until it's empty (not until a page is short), and why offset/page-number paradigms do not apply. Show the canonical loop.

2. **Page sizing** — recommend `limit` values per endpoint, the practical caps Slack enforces, and the tradeoff between fewer large pages and rate-limit headroom.

3. **Rate-limit integration** — handle HTTP 429 with `Retry-After`, classify endpoints by tier, and show a token-bucket or backoff wrapper that pauses pagination cleanly mid-loop and resumes from the saved cursor.

4. **Resumability** — persist the current cursor so a crashed or killed job restarts without re-reading everything; describe idempotent upserts so a replayed page can't duplicate rows.

5. **Consistency caveats** — explain that the dataset can change mid-paginate (new messages, deleted users), and how to detect/handle cursor expiry (`invalid_cursor`) and gaps.

6. **Thread fan-out** — for full-history exports, show how to page `conversations.history`, detect threaded parents (`reply_count`/`thread_ts`), and page `conversations.replies` per thread without N+1 explosions tripping limits.

7. **Observability** — log pages fetched, records seen, 429s hit, and total wall-clock; emit a metric for "pages remaining unknown" so a stuck loop is visible.

Output: (a) a reusable paginator (generator/iterator) for our SDK with built-in backoff, (b) the resumable-cursor persistence design, (c) a worked full-channel export example, (d) a test harness that simulates 429s and short pages.

Favor correctness and resumability over raw throughput.