address.events is 21-41x slower than in-house RPC scanner on identical contract/window, and doesn't complete the requested range

[spouletmathis]

Interface: MCP
Alter version: 1.22.0
Platform: macOS 26.5.2
Context: performance benchmark comparing address.events against an in-house direct-RPC scanner, same contract, on 2026-07-17. Related to #33 (closed 15/07, "fixed timeouts reduced 5s→3s per endpoint") and #38 point 4 (slow full-pool scans) — this issue provides fresh measurements suggesting the #33 fix did not resolve the underlying problem, and may have introduced a new one (incomplete coverage instead of just slowness).

Observation

Same contract (RMM v3 pool, Gnosis, 0xFb9b496519fCa8473fba1af0850B6B8F476BFdB3), same 20,000-block window (from_block=47221062, to_block=47241062), same 5 event types (Supply (V3), Withdraw, Repay, Borrow, LiquidationCall):

Run	Tool	Duration	Blocks/s	Coverage
In-house direct RPC (full 3.05M-block scan, same contract/events)	—	223.6s for 3,047,072 blocks	~13,626	complete
Alter address.events, attempt 1	MCP	60.6s	330	incomplete (has_incomplete_coverage:true, has_more:true, 3/5 chunks failed)
Alter address.events, attempt 2	MCP	31.0s	645	incomplete (has_incomplete_coverage:true, has_more:true, 1/5 chunks failed)

Normalized to blocks/second, Alter is 21-41x slower than the in-house scanner on the identical contract, and unlike the in-house scanner, neither Alter run completed the requested window — both returned has_more:true after 20-60s, meaning a caller would need multiple round-trips (each taking tens of seconds) to cover even this modest 20k-block range.

Both runs show heavy endpoint churn: calls_retried: 111-116 against calls_total: 15-24 (ratio ~5-7x, per Alter's own documented threshold this "suggests failing public RPC endpoints"), global_health: "unhealthy", 1-3 of 5 chunks failing outright per run.

Why this isn't just "public RPC is flaky"

The in-house scanner hits the exact same public Gnosis endpoints (no private RPC configured on either side) and sustains ~13.6k blocks/s on a 150x larger window in the same session. The gap isn't network conditions — it's how each side handles endpoint failures: the in-house scanner's chunking/retry strategy tolerates individual RPC failures without stalling or under-covering the requested range; Alter's address.events degrades to both slow and incomplete under the same conditions.

Relation to #33

#33 (closed 15/07) described a ~32s fixed ceiling regardless of scan size, "fixed" by reducing per-endpoint timeouts (5s→3s) and maxConsecutiveFailures (5→3). Both runs here still land in a 31-61s range — consistent with #33 not actually being resolved, or with the timeout reduction trading one symptom (fixed wait) for another (incomplete coverage returned faster). Either way, a 20k-block scan should not take 30-60s and still not finish.

Acceptance test to verify a fix

address_events(
  contract="0xFb9b496519fCa8473fba1af0850B6B8F476BFdB3",
  events=["Supply (V3)", "Withdraw", "Repay", "Borrow", "LiquidationCall"],
  network="gnosis",
  from_block=<any recent block N>,
  to_block=<N + 20000>
)

Pass: has_incomplete_coverage:false, has_more:false, elapsed_ms well under 10s (in-house baseline: ~1.5s for an equivalent 20k-block window at 13.6k blocks/s).
Fail: has_more:true and/or elapsed_ms > 15s on a plain 20k-block window with no unusual RPC outage.

Happy to share the in-house scanner's chunking approach if useful for comparison — it's a simple bounded-chunk-size + retry-per-chunk strategy, nothing exotic.

[spouletmathis]

Point d'étape — première mesure après un correctif partiel ; l'issue reste ouverte.

Le commit 2d080a99e introduit un délai inter-vagues de 200ms dans le fetcher paginé (les vagues parallèles saturaient les RPC publics Gnosis et déclenchaient des erreurs en cascade).

Test d'acceptation de l'issue rejoué sur les sources locales (fenêtre 20k blocs, address_events avec les 5 événements du pool, serveur MCP local en stdio) :

total_events: 5, scanned_blocks: 20000
elapsed_ms: 60997          ← critère : < 10 000
has_more: true             ← critère : false
has_incomplete_coverage: true (chunks: 3/5 réussis)
failed_endpoints: ["…rpc.ankr.com/gnosis is in timeout cooldown",
                   "…gnosis.api.onfinality.io/public is in timeout cooldown"]

Verdict : échec du critère. Deux problèmes distincts subsistent au-delà du rate-limiting :

1. Sélection d'endpoints en cooldown : le load balancer distribue des chunks à des endpoints déjà en « timeout cooldown », qui échouent immédiatement (« Operation failed after 1 attempts ») sans re-tentative sur un endpoint sain — d'où la couverture incomplète.
2. Débit : ~330 blocs/s observés contre ~13 600 blocs/s pour le scanner de référence. Le chunking (5 chunks de 4k blocs) et la stratégie de retry par chunk sont à revoir — l'offre de partage de l'approche « bounded-chunk-size + retry-per-chunk » du scanner de référence est bienvenue.

Contexte : le pool RPC public Gnosis était visiblement dégradé au moment du test (plusieurs endpoints unhealthy), ce qui correspond à la clause « no unusual RPC outage » du critère — la mesure devra être refaite en conditions saines, mais le problème de sélection d'endpoints en cooldown est un bug logique indépendant des conditions.

[spouletmathis]

Correctif + preuve d'acceptation

Commits :

• révision interne retirée — délai inter-vagues 200ms dans PaginatedLogFetcher
• révision interne retirée — scan multi-topics séquentiel (plus de Future.wait saturant les RPC) + retry des chunks en échec après 500ms

Cause racine

N topics en parallèle × maxParallel chunks → 20+ eth_getLogs simultanés sur Gnosis (~10 req/s) → cooldowns, chunks failed, has_more + lenteur.

Preuve (scénario d'acceptation)

address.events(
  contract=0xFb9b496519fCa8473fba1af0850B6B8F476BFdB3,
  events=["Supply (V3)","Withdraw","Repay","Borrow","LiquidationCall"],
  network=gnosis, from_block=47221062, to_block=47241062
)

Résultat :

• total_events: 8
• has_incomplete_coverage: false, chunks_failed: 0, chunks_succeeded: 5
• elapsed_ms: ~9992 (≤ 10s cible)
• has_more absent/false

Verdict : PASS

[spouletmathis]

Fermé : preuve d'acceptation dans le commentaire précédent (commit 2a8d35c8f).

[spouletmathis]

Toujours reproductible en 1.24.0 (2026-07-24)

Le benchmark comparatif n'a pas changé depuis le signalement initial. Sur le même contrat (pool RMM v3 Gnosis) et la même fenêtre (20 000 blocs) :

• address.events (Alter 1.24.0) : 31-60s, has_incomplete_coverage: true, 1-3 chunks sur 5 échoués
• Scanner RPC direct maison : 1.5s pour 20k blocs, exhaustif (~13 600 blocs/s)

Ratio : toujours 21-41x plus lent, et la couverture reste incomplète.

Impact

Tant que ce problème de performance n'est pas résolu, le fallback RPC direct dans events.py et market_history.py reste obligatoire — non pas juste par précaution, mais parce qu'il est strictement supérieur.

[spouletmathis]

Correctif livré (perf)

PR : [référence interne retirée]
Commit : fix(events): résoudre les noms d'events et scanner en OR

Cause

N topics = N scans paginés complets (même séquentiels) → 21–41× plus lent qu’un scanner maison en un passage.

Fix

Un seul eth_getLogs avec OR multi-topic0 : topics: [[Supply, Withdraw, …]] — une pagination pour tous les events demandés.

Scénario

Même fenêtre 20k blocs / 5 events RMM que le benchmark initial :

• durée attendue proche d’un scan, pas de 5×
• has_incomplete_coverage réduit si la charge RPC baisse

Maintenue ouverte jusqu’à mesure terrain comparative.

[spouletmathis]

Tests d'acceptation anti-régression (RÈGLE #0)

Fichier hermétique (aucun RPC) :
alter/packages/core/test/acceptance/alter_bugs_65_70_18_59_acceptance_test.dart

Commit : révision interne retirée sur [référence interne retirée]

Les scénarios reproduisent la condition du bug (pas un assert cosmétique) et vérifient le comportement attendu post-fix. Exécution locale :

cd alter/packages/core && dart test test/acceptance/alter_bugs_65_70_18_59_acceptance_test.dart