Most of the errors around scripts never returning a response or promises never completing means ther
Most of the errors around scripts never returning a response or promises never completing means there’s stuff being used in the global scope
KThe runtime can only see what was created in that request - so if Request B is depending on a global Promise from Request A then it sees that nothing is left in Request B yet it hasn’t returned a response.
KThat’s usually a different error though, “script will never return a response” or similar.
Dodd... I added some more logging, maybe I missed a throw or something on my promise.
Ddidn't think I had anything in my globals that would cause it
KI guess a theoretical downside that isn’t specific to S3 or R2 is that you might lose Content-Length if on-the-fly decompression is needed.
KIf you don’t need that header then it’s fine.
DCould it be a OOM error somehow?
Dactually I can test this, gonna try the same request on wrangler locally
DDwat
Dhow... how did a network connection lost cause a segfault?
DI think it's an OOM. It's trying to download a 70MB JSON file, parse it, compress it, and stringify it again lol
K
Dyeeeeeeeaaaah.
Daw fudge
DHow am I gonna tee the thing..
Dah, looks like it's okay? https://github.com/cloudflare/workerd/blob/main/src/workerd/api/streams/README.md#what-about-tees
GitHub
The JavaScript / Wasm runtime that powers Cloudflare Workers - cloudflare/workerd
KDepends what you’re trying to do - it generally only avoids memory usage when you’re consuming streams that are from outside of your Worker
Klike sending an R2 object to the client and to cache
Klike, when you parse it, how are you compressing it?
Duh it's pretty bad code tbh..
Kgotcha - I didn’t know how it’d work without stringifying before compression but that’s what you’re doing
Dthe thing is I'd need to know the size of the compressed gzip object to be able to upload it via S3 anyway
Dso gzip for huge objects is just never gonna work for me here
KMultipart is pretty much all you’d be able to do
DI wanna go to bed so I just made a separate path where anything over >16MB is not compressed at all 
Dwouldn't that get super messy because I want to return the same thing to the client?
Ais there some kind of limitation on making http requests from a worker? I have nextjs app that i am using
next-on-pages for; it has an api that gets deployed to workers that calls a graphql endpoint. it works fine locally, and using wrangler, but when deployed i get an error ApolloError: Unexpected token '<', "<html><hea"... is not valid JSONKWhat’s the URL you’re hitting?
KIt can’t be an IP or use custom ports.
Dcloudflared tunnels might work for @andrewmurphy.io, assuming he controls where the server stuff is run.
AIt doesn't use an IP or custom port.
https://courses.techleaderslaunchpad.com/graphql
Awhy should I need to tunnel to a publicly accessible URL?
Dif you were running on a custom port or IP
Aah okay, i am not 
Aoh, it also works fine on the build. the same API endpoint is called on the cloudflare build
Aso cloudflare can access that API fine on its build servers, just not from a worker
KThe build runs outside of Cloudflare’s infrastructure and from different IPs.
KIt’s possible that the website blocks Workers
KGiven that it’s only talking to Cloudflare, probably not.
Ait's just a wordpress instance that i host, so I doubt it
KFetch it without a client and see what
await response.text()what do you mean "without a client" ?
Aoh, you mean without apollo, just a fetch request
Agood idea, now i need to learn how to use fetch to make a graphql call 
K
KPersonally, it just tries to take me to a captcha - which a Worker can't do.
Aohhh, it'll be my hosting provider doing "smart" stuff. let me see if i can turn it off
Ajust confirmed you're right
<html><head><link rel="icon" href="data:;"><meta http-equiv="refresh" content="0;/.well-known/sgcaptcha/?r=%2Fgraphql&y=ipr:2a06:98c0:3600::103:1703826118.917"></meta></head></html> bny doing the raw fetch thing. now to work out how to get my hosting provider to turn that off