# fmmc5 entry reliability: answer to board #43 (Test Manager, 8 Oct 2026 ~21:00 Bangkok)

Read-only on firstmin (mc5.db, fm_mc5.py, public RPC). Nothing changed.

1. **429 at 8 Oct 08:05:48 (0x1dada094, the missed 19.5x).** The entry made one RPC attempt, got HTTP 429 and gave up (status err, no retry). **Already fixed:** fm_mc5.py now re-runs the entry up to 8 times on a transient RPC error while the coin is still in the entry window (entry(), dated 8 Oct, Ben). The file changed at 15:22 and the running process started 15:23, so the fix is live. No entry_retry has fired since. The log does not name the provider for this one 429; the same day shows Alchemy 429s ("billing or cap") 16:21-16:56 and paid dRPC 403s 16:19-17:01.
2. **GMGN "confirmation required" (6 Oct 19:03, 0x206211d4).** gmgn-cli asked for confirmation; the bot now passes --yes (FW v27). It has not recurred.
3. **"Submitted, no hash" (7 Oct 23:17 0x9312e871, 8 Oct 02:31 0x4edfad9a).** The hash is not missing; the log redacts every 64-hex string as <hex>. GMGN accepted the order, but no tokens arrived within fill_wait_s (30 s), so the bot booked buy_fail and moved on (no retry, no order-status check). The wallet holds 0 of both tokens now, so neither buy landed later and no ETH is stuck. Possible change (Ben's call, firstmin): on "submitted" with no tokens, query the GMGN order by order_id and, if it failed, retry once while still inside the entry window. Both of these coins were 0.45-0.49x in the harness, so these two misses cost nothing this time.
4. **0x4d8b2411 (6 Oct 13:27) never in mc5.db.** mc5.db's first record is 6 Oct 15:22; the coin is earlier, so the db cannot say why. Most likely the bot was not running or the db was started fresh after it.
5. **0xc0ef16fa cap_out** (245.5k vs 250k floor, harness 248k): measurement difference at the edge, not an execution fault.