Difficulty: Expert
Type: Performance
Recommended labels (if available in this repo): enhancement, reliability, performance
Background
src/contracts/providers/adaptiveContractProvider.ts and healthTracker.ts exist as scaffolding for adaptive provider selection across jsonRpcProvider.ts, webSocketProvider.ts, and multicall3Provider.ts, but the routing logic may be minimal or incomplete relative to a full health-scored failover system.
Problem
Without robust health-based routing, a single degraded (slow, erroring, or rate-limited) RPC provider can silently degrade the whole SDK's reliability instead of the adaptive layer routing around it.
Expected Outcome
adaptiveContractProvider.ts maintains a rolling health score per configured provider (based on latency, error rate, and timeout frequency from healthTracker.ts) and routes calls to the best-scoring healthy provider, with automatic recovery detection when a degraded provider improves.
Suggested Implementation
Extend healthTracker.ts to maintain a decaying-weighted score per provider (e.g. exponential moving average of success/latency/timeout signals). Implement selection logic in adaptiveContractProvider.ts that picks the best-scoring provider per call, with periodic health-check probes to degraded providers so they can recover into rotation without requiring a full app restart.
Acceptance Criteria
- Health score incorporates latency, error rate, and timeout frequency with configurable weighting
- A provider with a consistently high error rate is deprioritized in routing within a bounded number of calls
- A previously-degraded provider automatically recovers into normal rotation once its health score improves
- Unit tests simulate multi-provider scenarios: one healthy/one degraded, all degraded, and recovery over time
pnpm test:run passes
Likely Affected Files/Directories
src/contracts/providers/adaptiveContractProvider.ts
src/contracts/providers/healthTracker.ts
src/contracts/providers/adaptive.types.ts
src/contracts/providers/provider.types.ts
Difficulty: Expert
Type: Performance
Recommended labels (if available in this repo):
enhancement,reliability,performanceBackground
src/contracts/providers/adaptiveContractProvider.tsandhealthTracker.tsexist as scaffolding for adaptive provider selection acrossjsonRpcProvider.ts,webSocketProvider.ts, andmulticall3Provider.ts, but the routing logic may be minimal or incomplete relative to a full health-scored failover system.Problem
Without robust health-based routing, a single degraded (slow, erroring, or rate-limited) RPC provider can silently degrade the whole SDK's reliability instead of the adaptive layer routing around it.
Expected Outcome
adaptiveContractProvider.tsmaintains a rolling health score per configured provider (based on latency, error rate, and timeout frequency fromhealthTracker.ts) and routes calls to the best-scoring healthy provider, with automatic recovery detection when a degraded provider improves.Suggested Implementation
Extend
healthTracker.tsto maintain a decaying-weighted score per provider (e.g. exponential moving average of success/latency/timeout signals). Implement selection logic inadaptiveContractProvider.tsthat picks the best-scoring provider per call, with periodic health-check probes to degraded providers so they can recover into rotation without requiring a full app restart.Acceptance Criteria
pnpm test:runpassesLikely Affected Files/Directories
src/contracts/providers/adaptiveContractProvider.tssrc/contracts/providers/healthTracker.tssrc/contracts/providers/adaptive.types.tssrc/contracts/providers/provider.types.ts