fix(op-node/op-batcher/op-proposer): the fallback client should always try recover

[welkin22]

Description

In extreme cases, all of our endpoint URLs may be unable to connect, and the rpcInitFunc will return an error, causing the recoverIfFirstRpcHealth function to not have a chance to execute. So when the endpoint URLs are restored, our currentIndex counter still points to the end of the urlList array, causing internal state confusion in the fallbackClient and permanently disabling the fallback function until the node is restarted.

Rationale

We use defer to ensure that no matter what the situation, recoverIfFirstRpcHealth will be executed.

Example

none

Changes

Notable changes:

• Use defer to ensure that recoverIfFirstRpcHealth will always be executed regardless of the circumstances.
• Add a judgment condition to avoid mistakenly closing firstRpc with lastRpc.Close(), which will cause confusion in subsequent logic execution.

[github-actions]

This PR is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions]

This PR is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[andyzhang2023]

looks good.