yarn install - "trouble with your network connection"

[oliversturm]

I just installed ish yesterday, haven't changed anything about the alpine version or similar. I pulled in some of my usual Linux configuration files - zsh and emacs, for instance - and everything seems to be working fine. I did notice that all operations which require file system access are really slow - not sure if this is normal.

Now I installed node and yarn, and I'm trying to run yarn install on a test project of mine. Needless to say, this works just fine on my usual dev machine. I've tried it in ish several times now and the behavior is always the same:

• The initial "dependency" step of the yarn run works correctly - takes quite long, but it completes
• The "fetching packages" step begins and some packages are downloaded. Progress is slow but continuous.
• Suddenly a message appears in the last line: "There appears to be trouble with your network connection. Retrying..."
• The retries succeed (mostly) and a few more packages are downloaded
• Now the error message comes up more and more frequently, until eventually no more packages are downloaded and the error just keeps appearing. In my most recent run, I ended up with >20 subsequent errors before yarn gave up and quit.
• In the yarn error log I can see that the error in question is ESOCKETTIMEDOUT

As far as I can tell, the network connection on the iPad works correctly the entire time and other apps have no trouble using it. I'm on my home wifi which uses a fast fiber connection, so there's normally nothing slow about it. Technically I find it pretty weird how the problem escalates - I'm sure there's a reason for it, but it seems odd. Any ideas?

[62f]

#847 (comment)
I have a manifestation of network issues, among other problems while using an Apple 10W charger or any other which simply cannot keep up with the power drain. Caused me to rebuild curl and all its dependencies from source mistakenly thinking it was the problem: insatiability of all connections still ‘remotely-closing’ the connection proved it(curl) wasn’t to blame. The iPh.7s isn’t supposed to pull more than 1A, but somehow mine was. Lost power had to be leeching off to wideband RF/magnétic spectrum. Try checking your mains ground for open/microcurrent, but if you don’t have that skill set, just a different charger.

[oliversturm]

Hi @62f - I wasn't using any charger while doing the work described previously.

Also, your comments are not compatible with my (admittedly basic) understanding of how charging works in iPads. I thought that the devices always draw current from their batteries, and that this current draw is isolated from any charger which may be attached at the same time. In other words, as I understood it, an attached charger is never directly responsible for a supply sufficiently great to satisfy the current draw of the device. This explains how you can sometimes observe the charge indicator going down while a charger is attached - for instance when video-conferencing at the same time. Finally, on top of these points, I also have a hard time believing that the chipset in an iPad can be made to consume more power than can be supplied by its battery system...

Anyway, thanks for the observation, I'm sure there's something to it if it was consistent behavior for you. When I have a moment I'll do a test with a charger attached to see if this changes the behavior of my problem scenario.

[62f]

Au contraire. A charger is supposed to be able at its minimum rating to support the max load of the device by itself while holding the battery steady or even better: simultaneously charging it to the TDP limits of the passive cooling solution or in the case of active cooling, overcome the expected internal resistance of an aged battery well enough to reach the cv/cc charging parameters, all without upsetting the FCC(RF), UL(emitting blue smoke), or the C€(getting too hot). The problem with electrical isolation is that it all happens inside the charger with optocouplers, physical barriers and transformers. Once it gets to the bus(wire) everything else is solid state (transistorized), but Si is imperfect and makes poor filter capacitors, so the last-ditch fix for a junk DC converter which can’t keep up with its own advertised specs without breaking some laws is ferrite beads in the cable. If your charger lets the device battery go down at any time it’s connected, it’s junk. The power management software trying to save your battery by “learning your use patterns and not charging past 80% until you’re ready to use it” =horsehocky. The more ‘control’ you want, the more power you will consume. More power being used makes bad chargers to show more poor traits. Maybe you think a constant 80% battery is making out like a bandit, but unless you’ve got a really good cord, the battery’s having to absorb RF from the charger, which cycles and heats it up.

[oliversturm]

I see. Well, maybe you're an expert. However, it still doesn't apply to my problem because I was not using any charger.

[tomduncalf]

Hey, I also noticed this trying to install create-react-app (just out of curiosity!), it failed install rxjs every time. I did yarn config set httpTimeout 300000 and also added ~/.npmrc with timeout=300000 for good measure, and was able to install it. Everything with npm/yarn is pretty slow (10-100x slower than my laptop I guess?!) so it may just be that all the virtualisation etc. is slowing it down rather than some network thing?

[ntindle]

Will you add this to a wiki as a known workaround ?

https://github.com/ish-app/ish/wiki/What-works%3F

[tomduncalf]

Sure, I’ll do that tomorrow!

…

On Fri, 23 Oct 2020 at 19:35, Nicholas Tindle ***@***.***> wrote: Will you add this to a wiki as a known workaround ? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#929 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJURFV7MMMMICPVJG7SX63SMHEGVANCNFSM4SHBLTIA> .

[oliversturm]

The workaround with the timeout seems to work, thanks @tomduncalf . However, for yarn 1.x the option is called network-timeout instead of httpTimeout.

Apparently the underlying issue has been known for a little while, but there are no solutions so far: yarnpkg/yarn#8242 - it's not a network issue at all, caused by IO latency instead.

In my earlier tests I found that npm gave me similar trouble, but I didn't document details of it. It's peculiar that a separate tool should have the same issues... but that's obviously a separate topic.