AppCast download randomly results in various NSURLErrorDomain codes

[psulak]

We have a non-Sandboxed app that’s currently linked against Sparkle v2.3.2.

Our app’s had a long-standing random issue where Sparkle is unable to download the AppCast from our Server. We routinely see SUSparkleErrorDomain code SUDownloadError with underlying NSURLErrorDomain codes like:

-1001 (timeout)
-1003 (can’t find Host)
-1005 (network connection was lost)
-1009 (not connected to Internet)
-1200 (secure connection failed)

Ironically the reason we know these failure codes is that we have our app immediately Log the error to our Server via a POST NSURLSessionDataTask (which works even after the NSURLErrorDomain failure from the AppCast). We get maybe 10-20 new logs each day with this issue, all from unique IP's, different versions of macOS, and both Intel and Apple Silicon hardware. There doesn’t seem to be any rhyme or reason to the problem.

We've never been able to reproduce the problem in-house. But several years ago I added a “Retry” system when downloading the AppCast. We think that alleviated some of the problem, but it’s never entirely gone away.

Do you guys have any suggestions on what may be happening? Again, we’re a non-Sandboxed app. One thought I had (after browsing various issues here on GitHub) was that our AppCast URL uses HTTPS. But I was thinking about switching the URL to HTTP on the final attempt in my Retry system. Do you think that might help?

Thanks in advance.

[zorgiepoo]

Sparkle uses NSURLSession so I don't think these issues are specific to Sparkle.

In #2673 I had relatedly changed the timeout from 30 sec to the default one (60 sec). Just mentioning since there's some relation.

I strongly discourage using HTTP. It's less secure and you'll run into friction from Apple's frameworks.

[zorgiepoo]

It is possible the appcast is being fetched when the user is not in a good network state. Sparkle doesn't check for that. Even if you do a POST immediately after there is a potential race when the network state changes. Otherwise the issue would be related to connecting to your server.

[psulak]

Thanks for moving this to the Discussions folder Zorg:)

So it's certainly possible that the user's network condition is poor. That would explain a lot. As we all know, many things can go wrong when dealing with online communications. Does macOS have an API to report "general online status"?

Our app is heavily reliant on a working Internet connection. One thing we don't have is an easy way to compare the Sparkle AppCast failures against all further communications that we log. I think the first thing we'll do is try to "connect" that data to see if we can glean some additional info.

If it's okay with you, I'd like to leave this discussion open for a while to see if there are any other ideas or suggestions.

[zorgiepoo]

A long time ago Sparkle used reachability APIs but those were pulled out #836. Perhaps if after the request fails, you can use reachability but 'eh. From one point of view, a failure may be OK. If it's an automatic check, Sparkle will just check again at another time. Otherwise maybe the recent change to extend the connection timeout will help.

I generally leave Discussions open while Issues is more like the bug tracker.