fix(aa): fail over fast + quietly when primary bundler/paymaster is slow#26
Merged
Conversation
…is slow Root cause of the "error: This operation was aborted" seen mid-mint: an INTERMITTENT CDP latency spike. The CDP endpoint is reachable + fast for basic methods, but the heavier AA calls occasionally exceed the timeout. Two problems made a recovered failover look like a failure: 1. The bundler treated a timeout (AbortError) as transient and RETRIED the same hung provider up to maxRetries before failing over — up to ~90s of stalling on a dead CDP. Now `isNonTransient` flags timeouts so callWithFallback flips to the backup immediately. Bundler timeout 30s → 20s (paymaster already 15s). 2. The failover/retry messages were logged at `warn` and surfaced to the user — "error: This operation was aborted" during a *successful* mint. Downgraded to `debug` in BundlerClient + PaymasterClient. A total failure (both providers fail) still throws a clear, surfaced error. Net: occasional CDP slowness now fails over to Pimlico quickly and silently; the mint/pay just works. Full SDK suite green (2315); AA tests 53/53. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
DamirAGI
added a commit
that referenced
this pull request
Jun 9, 2026
Intermittent CDP latency now fails over to the backup bundler/paymaster quickly (timeout treated as non-transient; bundler 30s→20s) and silently (failover/retry logs warn→debug), so an occasional slow primary no longer stalls or prints a scary "aborted" mid-mint. Source merged in #26. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Root cause (investigated per request)
The
error: This operation was abortedseen mid-mint is intermittent CDP latency, not a deterministic bug:eth_chainId,eth_supportedEntryPoints) respond in ~0.3s — CDP isn't down.pm_getPaymasterData/eth_sendUserOperation) exceeds the timeout → AbortSignal → failover to Pimlico → succeeds.Two things made a recovered failover look like a failure:
maxRetriesbefore failing over — up to ~90s stalling on a dead CDP.isNonTransientnow flags timeouts →callWithFallbackflips to backup immediately. Bundler timeout 30s → 20s (paymaster already 15s).warn→ surfaced "error: This operation was aborted" during a successful mint. Downgraded todebug(Bundler + Paymaster). A total failure (both providers fail) still throws a clear error.Net: occasional CDP slowness now fails over to Pimlico fast + silently; the mint/pay just works (wow UX preserved).
Full SDK suite green (2315); AA tests 53/53.
🤖 Generated with Claude Code