(Click to enlarge)

(Click to enlarge)

This is a known issue. I cut you some slack because you probably don't know what's happening here. The setup wizard was attempting to download the Facebook Support non-bundled addon from the new composr.app server. Unfortunately, I've been experiencing many issues with connections prematurely closing when trying to download non-bundled addons. I have not yet been able to identify the issue, but I do know it's server-end on composr.app, not Composr itself.

The provider of the server, OVH, recently announced they're doing maintenance later this month in response to unwanted premature connection closures on the same data center which uses composr.app. I'm hoping their fix on April 24 will resolve this issue.

(side note) Good news is you confirmed telemetry works outside of my own server. When you encountered that error, because you had send errors to developers enabled, composr.app received your stack trace. So I know the new API and encryption system for that works.

See https://gitlab.com/composr-foundation/composr/-/commit/e66ec19b3ee1f8bdd4869bcf430ced6750074154

Do not have time to push a proper bugfix as I have a strict work cutoff of 12 AM EDT. This will be included in alpha2.

Here is context into what was fixed:

- composr.app's PHP-FPM was not spawning enough child processes to handle someone updating or downloading non-bundled addons. This was causing frequent timeouts and premature connection drops. I increased the pm.max_children setting for composr.app on the server.
- In Composr, a "partial file" status code in CURL was being treated as an error and resulting in failure. Instead of erroring immediately, it will now retry a couple of times fetching the remaining bytes before considering it an error / failure if it still doesn't have the full file.
- The downloads script (site/dload.php) was sometimes not returning the correct content length and range headers especially when CURL passes in a range (it uses 1TB instead of blank for the "to"... had to account for that; content length was also being set to the end range even if file size was not that big, which caused HTTP/2 stream errors).