-
Notifications
You must be signed in to change notification settings - Fork 48
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
feat: abort controller #183
Conversation
client.updateContext({ userId: '456' }); // abort 2 | ||
await client.updateContext({ userId: '789' }); | ||
|
||
expect(abortSpy).toBeCalledTimes(2); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also wanted to test error emitter on abort but the mocking fetch library does not support AbortController
@@ -89,6 +90,18 @@ export const resolveFetch = () => { | |||
return undefined; | |||
}; | |||
|
|||
const resolveAbortController = () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
similar pattern to how we handle fetch
…o abort-controller
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes! This is very nice
return () => new globalThis.AbortController(); | ||
} | ||
} catch (e) { | ||
console.error('Unleash failed to resolve "AbortController" factory', e); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should basically never happen, right? This is if someone is doing something unusual like swapping out fetch?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct - someone would need to take deliberate effort to end up in this situation
I keep getting these: the requests comes in pairs (within 2 seconds), and if I upgrade to v3.3.0 I get these every other request (so one is always downgrading to 3.2.0 fixes these for me. this is what Stack Overflow tells me about the |
@nammi-kobler those errors are expected when the requests are aborted e,g, when you're on a slow network and you have very short refreshInterval and the original request hasn't finished and you start the next one. From what I understand your refresh interval is 2s. Can you increase it and see if the problem persists? The abort operation should be an exception not a regular operation. |
The refresh interval is set to 15s, but for some reason they always come in pairs (every 15 sec), and then one of them always fails. any idea on why they would come in pairs? |
@nammi-kobler Can you check if this PR #207 fixes your issue? It's applied in the https://github.com/Unleash/unleash-proxy-client-js/releases/tag/v3.4.0 release |
Looks better, but it seems like it still happens over time |
@nammi-kobler Thanks for checking. So is it correct that the console.error is gone and now you're only left with the double request problem? Can you remind me if you use unleash-proxy-client-js directly or through react or nextjs wrapper? I couldn't reproduce this problem in this vanilla client so my guess is it's some wrapper adding those extra calls. |
we are using ![]() NextJS warning is from a wrapper that comes with Mantine I think? |
Are you running in Strict Mode by any chance? https://react.dev/reference/react/StrictMode |
haha yes. that's maybe the answer then. |
About the changes
Abort controller that aborts previous request when a new one is made.
Sample use cases:
Important files
Discussion points