Гайд
Почему шлюз повторяет одни методы на другом апстриме при сбое, а другие — никогда.
При сетевой ошибке на апстриме шлюз пробует другой апстрим — но только если вызванный метод идемпотентен. Список неидемпотентных методов задаётся настройкой продукта; для Ethereum это eth_sendRawTransaction.
Идемпотентный метод можно безопасно повторить: результат чтения блока или баланса не зависит от того, сколько раз вы его запросили. Отправка подписанной транзакции — другое дело: если апстрим успел принять её в мемпул до того, как соединение оборвалось, повторная отправка на другой узел не удвоит транзакцию (nonce защищает от этого на уровне сети), но и не даёт гарантии, что вы вообще узнаете, что первая попытка уже приняла её.
Для чтения (eth_call, eth_getBalance, eth_getLogs и подобных) можно не думать о ретраях — шлюз уже это делает. Таймаут на вашей стороне должен быть не короче суммарного таймаута шлюза с учётом возможного повтора.
Для eth_sendRawTransaction: если запрос завершился таймаутом или ошибкой апстрима, не отправляйте ту же подписанную транзакцию повторно вслепую — сначала проверьте eth_getTransactionByHash по её хешу. Если она уже видна сети, повторная отправка безвредна (сеть отбросит дубликат по одинаковому хешу), но не полагайтесь на это как на стратегию по умолчанию.
Ошибка апстрима всегда приходит в одном формате, независимо от того, какой именно узел её вернул и был ли активирован fallback-провайдер. По виду ошибки нельзя определить внутреннюю топологию — это осознанное решение, а не недоработка.