[Ayush7614]

Fixes #112

What changed

• The cursor can no longer go backwards. run() now writes cursor_block = GREATEST(cursor_block, $to) and head_block = GREATEST(COALESCE(head_block, 0), $head). Two sync machines that read the same cursor can finish out of order without the slower one pulling the cursor (and every later read) back to its own to. last_error is cleared only when the run reached the cursor already stored, so a lagging successful machine cannot hide a real newer failure. The error path keeps the highest observed head instead of replacing it with a lower one.
• One full poll pass per process. pollAll() is now single-flight. The per-chain run() guard already deduplicated run() itself, but two callers could still run the trader heal, quote-token heal, attribution backlog and holder backfill at the same time. The 15s loop and a web POST /api/launch/sync now share one pass.
• Trader healing pages the whole set, oldest first. healSwapTraders() used ORDER BY block_number DESC LIMIT 100 every tick. Rows whose transaction could not be read are parked in healRestUntil and skipped, but they still occupied those 100 slots, so the rows behind them were never selected. It now uses a keyset on (block_number, log_index), groups the page by transaction, and advances a per-chain cursor past every visited group — parked or not. At the end it wraps, so parked rows and rows added behind the cursor get another look. The pure planner is in traderHeal.ts; the DB page is 500 rows and at most 20 live transactions are read per tick, preserving the old RPC budget.
• Retry maps are pruned, not cleared. healRestUntil and attributionTries now drop expired entries first and then evict the oldest insertion when they reach 5,000 / 20,000 keys. The old clear() threw away every backoff at once, which let a burst of junk keys immediately retry rows that were supposed to rest.
• A partial index for the page. bb_launch_swaps_trader_null_idx on (chain_id, block_number, log_index) WHERE trader IS NULL matches the new filter and order, and stays small once the backlog is drained.

Why

The cursor write was last-writer-wins: with more than one app instance, a machine that finished block 190 after another finished 200 set the cursor back to 190. Every machine then re-read the overlap and could keep regressing. The trader heal had the opposite starvation problem: permanently unreadable transactions at the head of the newest-100 window kept every older missing trader out of the batch forever. Both are durability bugs that get worse exactly when the RPC is unhealthy.

Tests

• npm test: 1382 passed, 0 failed, 11 skipped (including 17 targeted indexer/schema tests).
• npm run typecheck: passed.
• npm run lint: passed.
• npm run build: passed (same three pre-existing filesystem-tracing warnings).
• traderHeal.test.ts: groups keep row order; parked groups spend no chain read; an all-parked page still advances the cursor; maxReads stops before the next live group; an empty page has no cursor.
• boundedMap.test.ts: expired retry entries are dropped before active ones; a full map with nothing expired evicts the oldest insertion; refreshing a key moves it out of the eviction lane; a burst of one-shot keys stays at the bound.
• indexer-durability.test.ts: pins the GREATEST cursor/head SQL, the conditional last_error clear, the single-flight pollAll wrapper, the keyset order, the bounded-map calls, the absence of the old newest-100 query and both clear() calls, and the partial index.
• schema.test.ts validates the new index against schema.sql columns.

Risk

No table or column changes. The new index is built by the existing CONCURRENTLY migration path. Per-tick RPC work is unchanged (20 transactions), and the 500-row DB page is covered by the partial index. The cursor is monotonic, so a reorg below the stored cursor is handled by the existing overlap window and the next successful pass, not by moving the cursor back.

Checks

pr-guard reports the app/db/concurrent-indexes.sql change as a review-tier finding, so that job stays red until an owner approves this exact head commit (the app, contracts, deps and guard jobs pass). The change is the partial index the issue asks for.

[coderabbitai]

Warning

Review limit reached

Only developers with an assigned seat can use this organization's usage-based review budget, and seats here are assigned manually. Ask an admin to assign a seat, or change the review continuation mode in Billing.

Next included review available in 40 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

• Configuration used: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: 010084a3-f986-4dfc-a88e-53455b573477

📥 Commits

Reviewing files that changed from the base of the PR and between 1e006c3 and 6e72822.

📒 Files selected for processing: 7

• app/db/concurrent-indexes.sql
• app/src/lib/launchpad/boundedMap.test.ts
• app/src/lib/launchpad/boundedMap.ts
• app/src/lib/launchpad/indexer-durability.test.ts
• app/src/lib/launchpad/indexer.ts
• app/src/lib/launchpad/traderHeal.test.ts
• app/src/lib/launchpad/traderHeal.ts

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[Ayush7614]

@kevincodex1 this is the indexer durability change for #112. The app, contracts, deps and guard jobs pass. pr-guard is red only because app/db/concurrent-indexes.sql is a review-tier path; the change is the partial index (chain_id, block_number, log_index) WHERE trader IS NULL that the new trader page uses. Could you review/approve that index when you get a chance?