Could you be a bit more precise? I assume you mean updating a 3.9.15 to current nightly, but I only can assume that, the desciption does not tell about the starting version.

@brianteeman I just see the "4.0" in the title. So you were trying to update from a 4.0 alpha? Then the branch "staging" in the issue tracker is wrong. Shall I change it? The reason why the update fails might be (if really 4.0) that script.php is not up to date regarding list of deleted files and folders, and so old files and folders remain.

i dont use the issue tracker so wasnt me that put staging

@richard67 it is current branch that I am updating - please try yourself

@wilsonge Any comments? Should this work?

if it doesnt work its a beta blocker but it would be best of someone else can replicate this first

Hmm the only changes between nightly build and current 4.0-dev I can see are scss and the atum overrides having been removed. No differences in SQL and no class files moved around ... so I would expect it to work.

@brianteeman Starting point was 4.0-dev with status of right now?

please just try it

Am just preparing ... but for other testers it could be really useful to provide more precise info in the description. That shall not be criticism, just a hint for improvement.

@brianteeman I've just tested and can't reproduce it.

Tested as follows:

1. Cleaned up my local 4.0-dev and pulled latest changes so it is absolutely identical with current 4.0-dev from right now, 2020-02-26 19:35 UTC.
2. composer install.
3. npm ci.
4. New installation without any additional stuff, no sample data, no languages, no nothing, having empty database.
5. Switched error reporting to maximum and server time zone to Berlin, like I always do.
6. Upload & Update with just downloaded nightly from today.
   Result: All fine, no 500, nothing in server log (with php error loggging into file enabled in my php.ini).

Maybe something is wrong with your 4.0-dev branch?

@brianteeman Please give more info about starting conditions: E.g. have you had any sample data installed?

Installed yesterday nightly build.
Updated with today's update.
No 500 errors.

@Quy As far as I understood, @brianteeman did vice versa, upated current 4.0-dev to the last nightly build.

And so I tested, too, and could not reproduce it.

I would not expect this to work normally, but this time I think it should work because no changes in SQL and no class files moved around, only css stuff changed and a few other non-relevant changes, so deleted files and folders not up to date in script.php should not be an issue here.

Maybe some sample data caused the problems? A while ago we had a case where an issue only became visibly because testing sample data was present, was causing some finder problem I think.

@brianteeman Please provide exact instructions to reproduce your issue. Based on assumptions it can not be reproduced. I want to make sure we match you environment exactly to ensure proper testing.

Not playing games with you

I did not want to play any games. I only wanted to know details to see if it is related to a particular starting condition, e.g. any installed sample data, or PHP version or database type and version and so on.

It's actually not related to PHP version or database type. Google the error message and you will see some information about it like https://www.howtoforge.com/apache2-mod_fcgid-http-request-length-exceeds-maxrequestlen

So basically, the reason of the error is the update package is too large. The solution is increased value of FcgidMaxRequestLen (I don't have mod_fcgid available on my local installation, so I don't know where to change it). But at least it gives us some information about this error.

@joomdonation that was it

So the question therefore is should that be checked in the same way as the max_upload is checked

Honestly, I'm unsure if it could be checked. Maybe the error 500 you are having is throwing by server before it reaches our php code for checking. You can try to add a die(); command here https://github.com/joomla/joomla-cms/blob/4.0-dev/administrator/components/com_joomlaupdate/src/Model/UpdateModel.php#L972 to see if the code in that method is executed in case error happens. If Yes, we might be able to check it. If not, maybe it's a server thing and could not be controlled by our code (I just guess only as I don't have any experience with mod_fcgid and do not have it here to test it myself)

yes it seems that you cant get that value from apache via php

While making the change in apache does resolve this I am not convinced it is correct. The reason is that joomla 3 on the exact same server does not have any problem at all

I don't think you can compare 3.x and 4.x here and say there is a code change causing the problem. The 4.x nightly ZIP builds are double the size of the current 3.x builds, so if it really is something to do with size then your culprit is the fact that the download package needs to be put on a massive diet.

As for the build on the issue tracker thing, that defaults to the default branch of the repository. It does not do any fancy parsing of titles or bodies to try and guess what to put for the build. And no, I would not encourage adding fancy parsing of titles or bodies to try and guess what to put for the build. It's already bad enough that issue titles have become version spam.