From software problem to a clear next step.
Choose a topic and what you need to do next. Add a search phrase to find a specific problem.
Browse 20 topics
Explore the playbooks
1500 guides · Page 2 of 60
-
Triage an API cursor pagination break
Find where a cursor, filter, or merge step skips or repeats API records so the missing page can be bounded before replay.
-
Prioritize API pagination gaps by downstream impact
Rank missing or repeated API pages by lost work, data freshness, replay cost, and confidence in a bounded recovery with a clear owner and review trigger.
-
Investigate skipped or repeated API cursor pages
Trace cursor creation, filter preservation, follow-up requests, and merge output to explain an API pagination gap with reproducible fixtures.
-
Verify API cursor pagination continuity
Prove API page traversal keeps filters, cursors, order, and identifier coverage intact across empty pages, retries, and changed datasets.
-
Learn from an API pagination gap
Capture cursor contracts, query checkpoints, coverage fixtures, and review signals so future pagination changes cannot hide missing records.
-
Triage an API filter encoding mismatch
Compare local filter state with the exact query sent and returned identifiers so an encoded API filter failure stays bounded and reproducible.
-
Prioritize API filter encoding failures
Rank incorrect API filter results by data exposure, missed work, consumer reach, and confidence in a narrow serialization fix.
-
Investigate API query parameter encoding
Build a reproducible filter investigation by comparing structured values, serialized parameters, server parsing, and returned records.
-
Verify API filter serialization and result scope
Test API filters with reserved values, repeated parameters, dates, empty states, and unsupported combinations to prove result scope stays accurate.
-
Learn from API filter encoding drift
Record filter semantics, serialization fixtures, unsupported combinations, and recurrence checks so query changes remain visible and bounded.
-
Triage an API rate limit burst
Locate the burst boundary, response timing, concurrency source, and queued work before changing API retry or capacity settings.
-
Prioritize API rate limit bursts by work at risk
Rank rate responses by essential work blocked, retry amplification, recovery window, and evidence for a safe concurrency change.
-
Investigate API rate limit headers and retry waves
Trace request concurrency, rate headers, backoff calculations, and queue attempts to explain a burst without assuming every 429 has one cause.
-
Verify bounded API rate-limit backoff
Exercise API rate responses, reset timing, missing headers, concurrency, and essential work to prove retries stay finite and useful.
-
Learn from repeated API rate-limit bursts
Maintain rate-response policy, concurrency fixtures, retry ownership, and review signals so bursts do not become synchronized recovery storms.
-
Triage an API idempotency key collision
Compare logical operation identity, generated key, payload fingerprint, and returned result before deciding whether a retry is safe.
-
Prioritize API idempotency key collisions
Rank key collisions by duplicate side-effect risk, affected operation reach, reconciliation cost, and confidence in a reversible containment.
-
Investigate API idempotency key reuse
Trace key generation, concurrency, request storage, remote result association, and retries to distinguish safe replay from key collision.
-
Verify safe API retries with idempotency keys
Test one operation across timeout and retry paths, distinct operations under concurrency, and missing key evidence before accepting an idempotency change.
-
Learn from API idempotency key collisions
Record operation identity, key scope, retry limits, reconciliation fixtures, and recurrence checks so safe retries do not cross-wire new work.
-
Triage an API timeout retry loop
Separate network timeout, remote completion, local retry, and operation state so an API retry loop can stop without losing reconciliation evidence.
-
Prioritize API timeout retries by duplicate risk
Rank timeout loops by unknown writes, retry amplification, blocked work, and confidence in safe readback or containment.
-
Investigate an API timeout retry loop
Trace dispatch, timeout classification, remote completion evidence, retry identity, and local state to find the first cause of repeated API attempts.
-
Verify an API timeout retry budget
Exercise pre-dispatch failures, delayed responses, unknown writes, readback, and process restarts to prove timeout recovery stays finite and safe.
-
Learn from API timeout retry loops
Maintain timeout classes, operation identity rules, retry budgets, readback fixtures, and recurrence signals so lost responses do not become duplicate work.