-
Notifications
You must be signed in to change notification settings - Fork 2
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
Dependency "cockatiel" does not work with Cloudflare Workers #3
Comments
I don't think I want to remove retry functionality entirely, but I could probably be convinced to make it configurable so that the package can be used without it. Maybe you can link me to a reproduction example of what you're facing? It doesn't have to be your full project, a minimal example would work too. |
Sorry been a while, coming back to this now... I've set up this example repo: https://github.com/davidhouweling/cloudflare-worker-halo-infinite-api In the main branch is the issue as outlined (though i'm not sure if more needs to be done to get Cloudflare Workers set up locally given that I've done it in the past so you may need to follow the getting started guide more closely... though you don't need to deploy to replicate the issue). I also included a Money patch original code change can be seen in https://github.com/davidhouweling/halo-infinite-api/tree/remove-request-policy |
If you wanted to simply override the native fetch, there is an optional parameter on all of the clients for doing just that. For instance, the HaloAuthenticationClient. halo-infinite-api/src/authentication/halo-authentication-client.ts Lines 78 to 80 in 37718d0
But it seems like native fetch is not actually your problem. Rather, the fact that cockatiel calls In between when you opened this issue and now it looks like you are not the only person who has noticed this, and someone else opened an issue with Cloudflare on this exact issue. I don't know much about the Cloudflare worker, so I can't say for certain, but that has all the smells of a bug in cloudflare rather than anything cockatiel is specifically doing wrong. As far as my idea to make cockatiel optional, that won't save you either. Since Cloudflare is bundling all code, even a conditional import will still evaluate that The only thing I can think to do is to publish my cockatiel-based retry policy as a completely separate package, then leave it up to the programmer to import it and pass a specific retry policy to the client. That way one could write code that completely skips over I think given that the narrow impact of this issue (Cloudflare workers), and the strong possibility that CF will patch this issue entirely, I'm going to hold off on making any such change at the moment. I'll leave this issue open until we get a response from them though. |
Yep I came to the same conclusion as you, which is why I went with a patch package approach. Similar to your summary, I don't think it's necessarily your responsibility to fix and the intersection between CF and this is quite small (I'm likely the only one at the moment) so at least it's documented here if someone needs the work around. |
Context
I'm working on creating an app using Cloudflare Wworkers and there is a collision with AbortController within cocatiel.
I could try and raise it with the owners there but i thought it might be quicker to start here.
I understand that it is presently used as a retry mechanism, I wanted to understand what the need for it was and whether you would be okay with dropping it, or perhaps doing a rudimentary retry without the use of cocatiel?
I do have a working approach locally where I've removed cocatiel but it no longer has the retry mechanism.
Thoughts on having me raise a PR to drop it?
The text was updated successfully, but these errors were encountered: