Conversation
|
👋 mxiao-cll, thanks for creating this pull request! To help reviewers, please consider creating future PRs as drafts first. This allows you to self-review and make any final changes before notifying the team. Once you're ready, you can mark it as "Ready for review" to request feedback. Thanks! |
NPM Publishing labels 🏷️🟢 This PR has valid version labels and will cause a |
alejoberardino
left a comment
alejoberardino
left a comment
There was a problem hiding this comment.
This should not be necessary, see #753 (review)
|
Can you explain why the fallback transport would go full speed? |
Fallback transport would go full speed because currently there is no difference between how a fallback and a primary is invoked. Let's say you have a 1 endpoint for rest and 1 endpoint with ws as primary and rest as fallback. The 2 rest endpoint invoked by the 2 endpoints will behave exactly the same. Given how fallback is intended to be only kick in after primary fail, I think it is ok for it go a little bit slower to save some resources. |
|
Wouldn't the rate limiter make sure it doesn't go full speed? |
Rate limiter would effect all transports, if the back-up transport is being used as a primary for a different feed, we don't want that to be effected. So I am looking for a lever that can adjust speed across different endpoints. For background sleep this is specified on the endpoint level, so I can say for this endpoint sleep and for that don't sleep. |
3 participants
Add ability to sleep between http background execute cycles.
One of the use case is fallback transport, we may not want the fallback transport to go full speed on fetching values.