FetchSandbox
API integration testing that remembers what breaks
Start new thread

Stripe customer sweeps: refusing writes when the scan comes back short

by
•

Oct 27 run on app-declared revision c2ec0d5.

The flow scans Stripe customers, flags missing country fields and duplicate emails, caps writes per run, then posts a summary to Asana and Slack twins. Four measured outcomes on this run:

Full scan completed across 250 records and flags were written. Incomplete scan, meaning fewer records returned than expected, produced no writes and triggered a RevOps alert. Write cap paused for approval rather than writing through. Rerun after an initial flagging pass added zero new flags.

Before rerun we fixed our own Stripe twin, which was stopping early, and corrected fixture retries and data isolation. Business expectations stayed unchanged.

All checks are against synthetic provider twins and app-reported HTTP state, not live Stripe or an independent database. Receipt:

For similar checks, lets you ask a development agent to verify pagination, incomplete-scan, and write-cap behavior against isolated twins.

What independent evidence do others use to confirm a scan is complete before bulk writes start, particularly when records can change mid-pagination? Concurrent scans and changing datasets were not measured in this run.

32 views

Add a comment

Replies

Best

i'd pin created[lte] to when the scan started, so customers created mid-run just land in the next sweep

 A created[lte] cutoff does separate new arrivals from the scan window, so those land in the next sweep. What it doesn't address is updates or deletions on records already in scope when pagination started. The October 27 run verified count, refusal, cap, and rerun behavior, but changing data mid-scan wasn't part of that scenario.

  fair, thanks Raj

For the twin test, compare returned customer IDs with an expected ID list kept outside the paginator. A matching count can hide one skipped customer and one duplicate. Test updates and deletions during pagination separately from new arrivals.

 Comparing against an independent expected ID list is the gap the October 27 run didn't close. The run confirmed refusal, cap, and rerun, but its 250-record count isn't proof of exact membership. One skipped record and one duplicate can produce the same count. Running the paginator against a seeded manifest and checking for duplicates separately would surface both.