[#963] Add txHash deduplication to indexer endpoints

[realproject7]

Summary

• Adds DB-first dedup check at the top of all 4 indexer endpoints (storyline, plot, donation, trade)
• Already-indexed txHash returns 200 { ok: true, cached: true } — skips all RPC/IPFS work
• Not-yet-indexed txHash processes normally
• No in-memory caching — serverless-safe (Vercel compatible)
• Compatible with plotlink-ows retry loop: successful index on retry returns cached success

Fixes #963

Test plan

• First submission of a txHash processes normally
• Second submission of same txHash returns { ok: true, cached: true }
• No RPC/IPFS calls made on duplicate submission
• plotlink-ows retry flow works correctly (cached response stops retries)
• All 4 endpoints have dedup check

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
plotlink	Ignored		Apr 23, 2026 11:33pm

[project7-interns]

Verdict: REQUEST CHANGES

Summary

The DB-first dedup pattern is fine for single-row endpoints, but the trade endpoint can index multiple rows per tx. The new early-return check treats any existing tx_hash + token_address row as a fully cached success, which can mask partial indexing and drop remaining trade logs on retries.

Findings

• [high] Trade dedup can incorrectly short-circuit after a partial insert. src/app/api/index/trade/route.ts now returns { ok: true, cached: true } if it finds any existing row for the submitted tx_hash and token_address. But the handler can upsert multiple trade rows for one tx (different log_index values). If the first attempt inserted one row and then failed before indexing the rest, a retry would hit this dedup check and skip the remaining logs forever. That loses trade history instead of just avoiding duplicate work.
  • File: src/app/api/index/trade/route.ts:29
  • Suggestion: Dedup trade retries at the per-log level, or only return cached success when the receipt's expected relevant logs are all already present (for example by comparing the set/count of matching log_index values).

Decision

Requesting changes because the current trade dedup logic can turn a retriable partial failure into permanent missing indexed rows.

[project7-interns]

Verdict: APPROVE

Summary

The re-review update resolves the blocking trade-indexer issue by removing the coarse early dedup from src/app/api/index/trade/route.ts, so retries can still recover partial multi-log indexing failures. The remaining DB-first dedup checks are confined to the 1:1 endpoints where they correctly avoid redundant RPC/IPFS work.

Findings

• No blocking findings.

Decision

Approving because the previous correctness issue in the trade route is fixed and the dedup strategy now matches the data shape of each indexer endpoint. Checks visible to me were still pending at review time.