Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: refactor cache client auth flow #589

Merged
merged 2 commits into from
Jul 8, 2022

Conversation

Harasz
Copy link
Contributor

@Harasz Harasz commented Jun 28, 2022

Description

Contributor checklist

  • Breaking changes - check for any existing interfaces changes that are not backward compatible, removed method etc.
  • Documentation - document your code, add comments for method, remember to check if auto generated docs were updated.
  • Tests - add new or updated existed test for changes you made.
  • Migration guide - add migration guide for every breaking change.
  • Configuration correctness - check that any configuration changes are correct ex. default URLs, chain ids, smart contract verification on Volta explorer or EWC explorer.

Copy link
Collaborator

@jrhender jrhender left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like a reasonable start 👍

One question I have is whether or not it is important to preserve the order of the execution of the failed requests?
Previously, we were doing this.failedRequests = this.failedRequests.filter((callback) => callback());. I think this likely would have run the requests in the order of the failedRequests array. In the new promiseRetry approach, we have several requests awaiting the same promise, but it's not clear to me which will be selected when the promise resolved. So if there were multiple database updates, they could be out of order, for instance.
Does this analysis seem correct?

@Harasz
Copy link
Contributor Author

Harasz commented Jun 28, 2022

It does not matter in my opinion. The execution of the failed request is manged by the code itself. We are operating in the same context of the promise. So if we have something like this

await update(1);
await update(2);

and update 1 will fail, it will try to run it 3 times and eventually it will fail, but update 2 will not execute, bc first update throw an error. So from the code perspective its the same promise that needs to be fulfilled.

@jrhender

@Harasz Harasz force-pushed the task/ICL-299-auth-promise-retry branch from 4572194 to 6b92779 Compare June 29, 2022 12:15
@Harasz Harasz changed the title feat: retry promise chore: refactor cache client auth flow Jun 29, 2022

private async makeRetryRequest<T>(request: () => Promise<T>): Promise<T> {
return promiseRetry(
async (retry) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is async necessary here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so, thanks for catch it

Copy link
Collaborator

@JGiter JGiter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting approach. May be it is possible to wrap axios API with promiseRetry in order to not repeat in every method

@Harasz
Copy link
Contributor Author

Harasz commented Jun 30, 2022

@JGiter hymm, it would be great, but i dont think it's possible :/

@artursudnik
Copy link
Member

Have you considered using Axios interceptor to implement retrying failed requests?

@Harasz
Copy link
Contributor Author

Harasz commented Jul 1, 2022

@artursudnik request interceptor is only accepting axios config, so i can't override promise there. I can use response interceptor and catch errors, but it's not an ideal approach in my opinion.

@Harasz Harasz force-pushed the task/ICL-299-auth-promise-retry branch from 6b92779 to 4e44445 Compare July 7, 2022 07:32
@Harasz Harasz marked this pull request as ready for review July 8, 2022 07:58
* chore(cache-client): refactor request error handler

* test(cache-client): add authorization tests

* chore: use correct logger methods
@Harasz Harasz merged commit fcbd34e into develop Jul 8, 2022
@Harasz Harasz deleted the task/ICL-299-auth-promise-retry branch July 8, 2022 12:59
@ewf-devops
Copy link

🎉 This PR is included in version 6.0.0-alpha.29 🎉

The release is available on:

Your semantic-release bot 📦🚀

@ewf-devops
Copy link

🎉 This PR is included in version 6.0.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants