mailchimp batch subscribe timed out halfway and agent had no record of who was added

TL;DR

Split the subscribe list into small chunks, poll the batch status endpoint until each chunk reports finished, and checkpoint the last completed chunk to durable storage. Retries check membership first, so already-added contacts are skipped. A timeout costs one chunk, never the whole job.

mailchimp batch subscribe timed out halfway and agent had no record of who was added

Use this when

• a bulk subscribe call times out partway through
• the agent has no record of which contacts were added
• retries risk double-subscribing people
• subscribe jobs are large enough that one call cannot cover them

Not for this skill when

• the subscribe API rejects addresses for being invalid
• you need help with email content or campaign setup
• the list itself needs cleaning or re-permissioning

Steps

1. Split the subscribe list into small chunks (a few hundred per batch call) so each call is fast and cheap to retry. Expected: a timeout loses one chunk, not the whole list.
2. After submitting a batch, poll the batch operation status endpoint until it reports finished, and record the per-chunk result. Expected: you know exactly which chunk completed.
3. Checkpoint the last completed chunk to durable storage before starting the next. Expected: a crash resumes at the next chunk.
4. Before retrying a chunk, check membership for its addresses so already-added contacts are skipped. Expected: retries add only the missing contacts, no duplicates.
5. On repeated timeouts, back off and shrink the chunk size instead of hammering the endpoint. Expected: the job finishes slowly rather than failing loudly.

Variant phrasings

bulk subscribe timed out with no progress record

Short version: chunk the list, poll batch status, checkpoint each completed chunk.

agent lost track of who was subscribed

Short version: check membership before retrying a chunk so retries only add the missing.

subscribe retry double-added contacts

Short version: membership checks make every retry idempotent.

Compatibility: written for the Mailchimp batch operations API; the chunk, checkpoint, and membership-check pattern ports to any bulk subscribe endpoint. Read the API key with os.environ.get("MAILCHIMP_KEY") and never log it.

Why it happens

The agent fired one giant subscribe call, it timed out, and nothing recorded partial progress. The API may well have processed part of the batch, so a blind retry double-adds people while a cautious no-retry leaves gaps. Without chunking and checkpoints the agent cannot know where it stands.

Edge cases / pitfalls

• The batch status endpoint can lag; poll with a timeout and treat long-pending batches as unknown, then verify by membership.
• Membership checks on huge chunks are slow; check in pages and cache results for the retry window.
• Shrinking chunks forever can stall the job; set a floor and alert if it is reached.
• A timeout does not mean nothing was added; never assume the failed chunk is empty.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fusvHLyrRhLSIqeRB9kjyA