deno: Consuming certain HTTPS fetch responses fails with "unexpected end of file"

As a workaround, I’m thinking about just retrying the fetch when the bug occurs. Something like this: https://dev.to/ycmjason/javascript-fetch-retry-upon-failure-3p6g

For me, the bug rarely happens twice in a row, so maybe I can get past it by just retrying x number of times.

Update This workaround/hack worked great. The bug still occurred 7 times out of 207 fetches, but it never occurred twice in a row in my test. Although I coded it to re-try up to 10 times, each time the bug occurred (those 7 times), on the very next try the fetch succeeded.

All I did to my code was add this function at the top, and then I used fetch_retry() instead of fetch() throughout the entire script.

const fetch_retry = async (url, options, n=10) => {
	let error;
	for (let i = 0; i < n; i++)
	{
		try
		{
			console.log(`Try ${i+1}`);
			return await fetch(url, options);
		}
		catch (err)
		{
			error = err;
		}
	}
  throw error;
};

The function above was written by Jason Yu. The only modifications I made to it, were (1) I made n default to 10 (tries), and (2) I added a console.log() so I could see when the re-tries occurred (oh yeah, and I changed white-space a bit). To see Jason Yu’s function without my modifications, go here.

In summary, I consider this a terrible bug that should rank very high on Deno’s ToDo list. Fetch is a fundamental utility that should be rock solid in each deno release. However, I’m glad this bug happened: because it caused me to make my own code way more robust (with or without this bug).

No fix? not even some monkey-patch?

Like what do I do now? Re-write the entire project in another language? 😕

@Lonniebiz I used this workaround and tried fetching the data 100 times, but the error occurs every single time for me. Are there any other workarounds/fixes available?

This is an upstream bug: rustls/hyper-rustls#162

Guys, I’m looking for practical solutions that I can implement until this is fixed.

For example, I running deno verison 1.22.2 on this project. Does anyone know which version of Deno precedes this bug? Perhaps I can downgrade to a version of deno where this bug goes away, and later upgrade to the latest deno once it is confirmed fix.

It is my understanding that the reason Deno is throwing this error, is because the web server I’m requesting from isn’t always “sending a CloseNotify alert before closing their response stream”.

I tire very quickly of frameworks that prioritize correctness over robustness. Something that’s not correct is only worthy of a warning if that lack of correctness can be ignored to achieve robustness.

What I assume is the same issue is also causing Deno to fail to cache deps or run type checks on GitHub Actions CI, which has broken my app’s builds. For some reason it doesn’t seem to happen on my local MacOS Deno, even though it’s the same version.

Run deno run ... --unstable --no-check scripts/test-setup.ts
...
Download...
error: error sending request for url (https://deno.land/x/god_crypto@v1.4.9/src/utility/asn1.ts): connection error: unexpected end of file
    at https://deno.land/x/god_crypto@v1.4.9/src/rsa/export_key.ts:4:21
Error: Process completed with exit code 1.

and

Run deno cache --import-map=import_map.json --unstable scripts/test-setup.ts
Download...
error: error sending request for url (https://deno.land/std@0.113.0/streams/conversion.ts): error trying to connect: tls handshake eof
    at file:///home/runner/work/.../core/objstore/objstore.ts:4:42
Error: Process completed with exit code 1.

I have re-run the tests several times and they fail similarly each time, though often on a different file.

This is Deno 1.17.0 running on GitHub Actions default ubuntu runner.