Define separate fallback RPC argument to work around URL escaping issues #777
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.
This change adds a optional fallback RPC as a separate argument to isolate primary from secondary RPC and avoid dealing with shell escaping issues with concatenating multiple URLs into a single argument.
The required CHAIN_RPC flag still supports multiple RPC urls via string slice, but with this change recommendation is the use single RPC URL (as primary) and specify fallback via CHAIN_RPC_FALLBACK, which gets appended to the EthClient RPC list.
Why are these changes needed?
Updating secrets needs to be high confidence and simple. Engineers should not need to worry about shell escaping or urlencoding api keys in a string slice arg.
Using github secrets with multiple RPCs concatenated into one is also problematic/error prone for updates.
Background: Our ankr enterprise RPC url includes a query param
?api=xxx
which breaks helm diff when used in a string slice.Checks