You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
When partial outages occur as during the past few weeks, dapps built on NEAR stop functioning due to only attempting to connect to a single endpoint URL, which may be unreachable and/or unresponsive.
Describe the solution you'd like
In addition to config.nodeUrl (a string), add support for config.nodeUrls (an array of strings). This way multiple node URLs can be configured, with the primary (first) URL used by default and the others as fallbacks in case the primary is unreachable or unresponsive.
Describe alternatives you've considered
While it's certainly possible to do all this on the user level, by catching errors and then creating a new connection to another endpoint URL, that would be complex and buggy, and that would interact badly with the retry logic inside near-api-js. It's best to provide this facility in near-api-js, hence making all NEAR dapps more robust.
Additional context
As discussed in the post-mortem incident review today, this would have alleviated the troubles during the past several weeks.
The text was updated successfully, but these errors were encountered:
This could be especially useful for apps that use their own endpoints but can set a fallback one in case of some maintenance, etc. And this also would help with the decentralization of endpoints.
Is your feature request related to a problem? Please describe.
When partial outages occur as during the past few weeks, dapps built on NEAR stop functioning due to only attempting to connect to a single endpoint URL, which may be unreachable and/or unresponsive.
Describe the solution you'd like
In addition to
config.nodeUrl
(a string), add support forconfig.nodeUrls
(an array of strings). This way multiple node URLs can be configured, with the primary (first) URL used by default and the others as fallbacks in case the primary is unreachable or unresponsive.Describe alternatives you've considered
While it's certainly possible to do all this on the user level, by catching errors and then creating a new connection to another endpoint URL, that would be complex and buggy, and that would interact badly with the retry logic inside near-api-js. It's best to provide this facility in near-api-js, hence making all NEAR dapps more robust.
Additional context
As discussed in the post-mortem incident review today, this would have alleviated the troubles during the past several weeks.
The text was updated successfully, but these errors were encountered: