Add timeout + default setting to Arbitrum RPC requests
Description
Expose RPC timeout setting as environment variable
add timing logs
Changes
Steps to Test
Quality Assurance
- [ ] If a new adapter was made, or an existing one was modified so that its environment variables have changed, update the relevant
infra-k8sconfiguration file. - [ ] If a new adapter was made, or an existing one was modified so that its environment variables have changed, update the relevant
adapter-secretsconfiguration file or update the soak testing blacklist. - [ ] If a new adapter was made, or a new endpoint was added, update the
test-payload.jsonfile with relevant requests. - [ ] The branch naming follows git flow (
feature/x,chore/x,release/x,hotfix/x,fix/x) or is created from Jira. - [ ] This is related to a maximum of one Jira story or GitHub issue.
- [ ] Types are safe (avoid TypeScript/TSLint features like any and disable, instead use more specific types).
- [ ] All code changes have 100% unit and integration test coverage. If testing is not applicable or too difficult to justify doing, the reasoning should be documented explicitly in the PR.
⚠️ No Changeset found
Latest commit: d7a4ed1d37e9a25c3adb0f31580e365ad528c09c
Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.
This PR includes no changesets
When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types
Click here to learn what changesets are, and how to add one.
Click here if you're a maintainer who wants to add a changeset to this PR
Why do we need this?
Why do we need this?
@mxiao-cll the default timeout is 2 min in the current ethersjs version (source)
It probably might not ever hit this if the background execute timeout is shorter - but if we don't set something reasonable isn't it possible for the background execute to freeze up?
Why do we need this?
@mxiao-cll the default timeout is 2 min in the current ethersjs version (source)
It probably might not ever hit this if the background execute timeout is shorter - but if we don't set something reasonable isn't it possible for the background execute to freeze up?
Q1: What kind of heavy request are we doing here that may exceed the default timeout
Q2: What do you mean background execute to freeze up ? If background execute timeout the request will be cancelled AFAIK