MacOS can no longer check for updates

[momack2]

• OS: MacOS
• Version of IPFS Desktop 0.10.4

Describe the bug
Cannot connect to internet to check for latest version since 0.5 release

To Reproduce
Steps to reproduce the behavior:

1. about
2. check for updates
3. see "could not check for updates, not connected to the internet"

Expected behavior
my node finds the new version and installs it

Additional context
On Tuesday morning PST I was able to check for updates (and was told my node was up to date). As of Wednesday PST I was no longer able to check for updates.

Logs:
combined.log
error.log

[lidel]

Unfortunately logs do not tell us much:

2020-05-04T04:44:09.180Z info: [updater] update available. download started
2020-05-04T04:44:39.197Z error: [updater] Error: Request timed out
2020-05-04T04:44:39.198Z error: [updater] Error: Request timed out

it looks similar to this upstream issue: electron-userland/electron-builder#4744 which seems to be why people hardcoded older version v4.2.2: unipept/unipept-desktop#28 (comment)

---

I did some initial analysis and:

ipfs-desktop v0.10.4 is using electron-updater v4.2.4
ipfs-desktop v0.11.1 is using electron-updater v4.3.1 (recent bump: #1462)
ipfs-desktop v0.11.2 is using electron-updater v4.3.1

@rafaelramalho19 are you able to do some smoke-tests of update mechanism on Mac/Windows?
(to see if the problem is limited to Mac, and if its still the problem in v0.11.x)

1. Do a fresh install of v0.10.4 and reproduce the issue (menu→about→check for updates)?
   (make sure to manually remove directory with ipfs-desktop config etc)
2. Check if the problem is still present in v0.11.1 by doing the same?

[rafaelramalho19]

Smoke test on 0.10.4 is breaking:

Same for 0.11.1, but appears to be a different "alert":

[rafaelramalho19]

Upon further investigation and some wizarding debugging, I found that error is thrown whenever the auto-updater is trying to update a non-signed app.

@momack2 can you confirm that you were using a version built from the source code (or without signing) instead of the one available from releases?

[autonome]

Non-signed or non-notarized?

[lidel]

It is both, but here we suspect signing:
Non-signed == built from sources locally instead of using prebuilt .dmg fetched from releases page.

[momack2]

The last thread I have on the topic is #1067 - where it looks like I installed the beta for 0.9.0. I believe I used the auto-updater after that to get my node to 10.4.

[rafaelramalho19]

@lidel you have any suggestion oh I can look further into this? I wasn't able to get a response from the community where they also had the same problem as Molly 😕

[lidel]

@momack2 so the good news is that (so far) we were not able to reproduce the problem with the signed/notarized release versions.

The only time @rafaelramalho19 was able to get the same error as you was when he run local developer build which was not signed. Not sure if your setup is similar, or perhaps something you installed along the way had similar impact.

Either way, afaik regular users that installed ipfs-desktop v0.10.4 are not impacted and autoupdate seems to work as expected.

---

@rafaelramalho19 before we close this as "not reproducible" let's make a final check:

Please find someone who had no prior IPFS installation and do a fresh install of v0.10.4 and try to force update to v0.11.2 via menu→about→check for updates

..or manually remove everything that Desktop touches, on linux its:
rm -rf ~/.ipfs ~/.ipfs-desktop ~/.config/Electron ~/.config/IPFS\ Desktop
(not sure what is the location of .config ones on macOS, but its a directory with Electron store's config.json)

[rafaelramalho19]

I asked a colleague of mine to install it and it worked fine. I also did what you said about the clean state and it also worked fine 😄

[autonome]

Do we have a migration regression test? Would be great to have a test that:

• builds and sign previous version
• configure update url to local web server
• install, and start
• add set of example data
• build and sign current version
• check for updates
• install update

[momack2]

+1 - we should get that test.

We should also run a test that installs a random previous version (I think my last one was 0.9.0, which afaik wasn't signed) and then checks for updates manually (or tries to auto-update), to test whether that feature is working.

We also have error logs from countly we can be checking to see other automated reports from users with metrics reporting enabled. Can we use this to estimate the impact of this issue?

[Stebalien]

I've removed the externally installed go-ipfs version and am still getting this issue with the auto-installed version.

I installed ipfs-desktop not so long ago (a month or two?) through the dmg.

[Stebalien]

Do we have metrics on how many users managed to upgrade?

[jessicaschilling]

Here's the version distribution of users since 27 April:

Top versions are:

• 0.10.4: 3836
• 0.11.2: 2434
• 0.11.1: 345
  (0.11.1 was the first version to ship with go-ipfs 0.5)
  That represents 2779 upgrades vs 3836 users on 0.10.4, though we can't assure how they upgraded.

[jessicaschilling]

(this was also discussed in an email chain: @lidel notes "I suspect people are not running IPFS all the time and autoupdate can't happen when Desktop app is not running, so it will take time to migrate everyone.")

[Stebalien]

Can we distinguish between upgrades and new installs?

---

On topic: I've disabled the gatekeeper and it doesn't make a difference. Something here is borked.

[jessicaschilling]

Can we distinguish between upgrades and new installs?

Not that I'm aware of, but I'm new to Countly.

[jessicaschilling]

Not quite what @Stebalien is asking for, but session frequency is interesting:

112 first sessions since 27 April, but the vast majority of non-new sessions are on a frequency of at least once a day. This might indicate our auto-update rate should be pretty high even given @lidel's point about auto-update not happening when the app isn't running ...

[lidel]

@momack2 confirmed her Desktop updated from 0.11.2 to 0.11.3 🚀
This means autoupdate on macOS works (at least for people who installed post go-ipfs 0.5.0)

Should we close this?

[momack2]

Can confirm that our other mac device that wasn't manually upgraded to 11.2 still experiences the previous issue (unable to check for updates) and is stuck on 10.4 without a manual bump.

[jessicaschilling]

Are we able to close this based on enhancements in https://github.com/ipfs-shipyard/ipfs-desktop/releases/tag/v0.11.4 ?

[lidel]

We can't do more for <0.11.2, but believe 0.11.4 hardens things enough to close this.
@momack2 your call