(Feature) - 1029 Improve Polling behaviour #1047
Conversation
|
Travis automatic deployment: |
|
Travis automatic deployment: |
…29-improve-polling # Conflicts: # yarn.lock
|
Travis automatic deployment: |
|
Travis automatic deployment: |
2 similar comments
|
Travis automatic deployment: |
|
Travis automatic deployment: |
…to 1029-improve-polling # Conflicts: # src/routes/safe/store/actions/fetchSafe.ts
|
Travis automatic deployment: |
|
Travis automatic deployment: |
|
Travis automatic deployment: |
|
Travis automatic deployment: |
|
Travis automatic deployment: |
|
Travis automatic deployment: |
|
Travis automatic deployment: |
2 similar comments
|
Travis automatic deployment: |
|
Travis automatic deployment: |
Agupane
requested review from
fernandomg
and removed request for
fernandomg and
nicosampler
|
Travis automatic deployment: |
| }) | ||
| } | ||
|
|
||
| const incomingTransactions = await loadIncomingTransactions(safeAddress) |
There was a problem hiding this comment.
Why is this bot using the backoff?
| dispatch(addIncomingTransactions(incomingTransactions)) | ||
| export default (safeAddress: string) => async (dispatch: Dispatch): Promise<void> => { | ||
| try { | ||
| const transactions = await backOff(() => loadOutgoingTransactions(safeAddress)) |
There was a problem hiding this comment.
I would set a maximum delay of like 5 or 10 min else this will completely break the ux if the service is down for a couple minutes.
There was a problem hiding this comment.
it fetches the data continuously, if this request fails, the interface will send a new one
There was a problem hiding this comment.
Yes, but it increases the delay (*2) so at some point this will be a very long delay (not critical as it can be reset with a reload :) )
There was a problem hiding this comment.
@rmeissner https://github.com/coveooss/exponential-backoff#readme the defaults seem to be ok imo
There was a problem hiding this comment.
Actually looking at it the default values are not the best for oir use case. 100ms as a default delay makes not too much sense in my opinion as this will only triggered more failed request really fast. I would probably set this to 5 or 10 seconds. And in this case 10 retries with infinitive delay is quite a lot (~1.5h delay with 5 seconds)
Closes #1029
Description
exponential-backoffdependency for implementing backoff in case that a request failweb3.utils.toChecksumAddresswith an utilchecksumAddressuseCheckForUpdatesto usesetTimeoutinstead ofsetIntervaland rename it touseSafeScheduledUpdatesUPDATE_SAFEactionWe could probably in another pr improve this and maybe try the library that @nicosampler suggested :) but at least for now I think it solves our current problem