Error 500 on upgrade 5.9.4 -> 6.0.5

[murugappan]

Hi ,

I just did an upgrade of my espo instance from version 5.9.4 to 6.0.5 using CLI. The update and rebuild were successful. Started up upgraded instance but failed with an error 500. The error is in the attached log (screencap 1).

This is what i did:

(1) Restore a production version of the core and database version called "emasdmstg" as "emasdmstst".
(2) Change the config,php to use the emasdmstst database.
(3) Did a CLI rebuild. Good.
(4) Start up emasdmstst.Good.
(5) Tested all the functionality:Good.
(6) Used CLI to upgrade using the SSH command: "php command.php upgrade"
(7) Upgrade command successful.
(8) Used CLI command: "php rebuild.php". Successful
(9) Start up upgraded version: Failed with Error 500 as shown in screencap 1.

Please help!

[espcrm]

I noticed that it is a custom file, I got an error with a custom file too during my upgrade. How I manage to upgrade (without waiting for a solution) is to remove these file temporary.

[murugappan]

Hi espcrm, thank you for the suggestion. I will try it. The only concern i have is will there be any database table alterations.

[murugappan]

espcrm hi,

I tested out the suggestion. This is what i did:

(1) I renamed the custom->espo folder
(2) Performed the upgrade (wow, yesterday was 6.0.5 and today is 6.0.6)
(3) Did a rebuild
(4) Renamed the espo folder
(5) Started instance and it failed with the same error.

Appreciate if you could verify the above steps and advise if I should do change otherwise this has to be posted as a severity bug.

[espcrm]

Does that mean you manage to upgrade already and it just that you can't use the Custom service? Or you can't upgrade at all even though you rename the custom folder?

Can't really help you much to be honest, I always panic fix these kind of issue and don't keep notes of it. Only way I think I could help is: if you could post the Services, I can test it on my version and see if it crash for me also.

But reading the filename "BIllRecord", I don't think I have the Sales Pack (?) to test it either way.

[murugappan]

Hi Espcrm, Thank you for all the assistance. I could perform the upgrade and do the rebuild but could not load the app. When i start the app it crushes with an error 500. No login form.

[murugappan]

Looks like i have suspend the upgrade until i get some reply. I always never try to upgrade to X.0 versions. Very risky. Is there any help from people in Espocrm??

[espcrm]

If that the case then it would be an issue with with the app isn't it? Best to post it in a separate thread because this thread probably won't get looked at.

[murugappan]

Hi espcrm, The problem is resolved. Please see my post #10 below. Silly problem really.

[Maximus]

Hi murugappan,
I've moved your issue thread to the particular topic, so you don't need to create a new one.

Well, so the system is upgraded but it still crashed upon the custom file. Please provide the code of the file /custom/Espo/custom/Services/BillRecord.php.
Do you have BillRecord entity? Or it is deleted?

[murugappan]

Maximus Hi,

Thank you so much for the help and guidance. I found the problem. I was so dumb i didnt realise it was pointing to a php script with "(original)" in its name. That script was the original script that was created when i created the "billrecord" entity. Subsequently i modified the script to include duplicate checking on a field. Before modifying, i did a backup of the original code and labelled it as "Billrecord(original).php". Somehow the system attempted to use this script as well. That was the cause of the problem. Sigh! I removed this "original" script and it is working fine now. Appreciate if you explain this. I have included the two scripts in the attached zip file.

This did not happen in all the versions before version 6.x. I still have the script in version 5.9.4 but no issues. I am surprised on why the version 6.x looked at this script in the custom folder. Is there a some change in version 6.x or is it a bug?

[Maximus]

So you had 2 files (Billrecord.php and Billrecord(original).php) in the custom/Espo/Custom/Services directory simultaneously. When you made Rebuild (Rebuild starts before the upgrade process. Rebuild runs Clear Cache procedure) the system Cache was cleared, so the system add these 2 files to the /data/cache/application/classmapServices.php file. Obviously that file the Billrecord(original).php with default class name 'Billrecord' will cause the issue.
I think this issue also might appear in the 5.9.4 version if you would make Clear Cache.

[murugappan]

Hi Maximus, unfortunately this does not happen in 5.9.4 . We regularly do a rebuild after each change. There has bee no issue so far. Version 5.9.4 works fine with the 2 files. Anyway, i removed the backup file. Thank you so much again.

[Maximus]

I can confirm that this didn't cause the issue in the EspoCRM prior to v.6.0. As far as I am aware of there were a lot of changes. Be careful when you making some code change.

[murugappan]

Hi Maximus, thank you for the advise. I have a software called Beyond Compare which does the checking for me. I have the habit of backing up the original code and naming with "(original)" suffix and the i make the changes. The when new version get loaded i get Beyond Compare to check the code for me. Anyway the code changes we suggested by espocrm developers.

[espcrm]

At least it is resolve!

-- Going off-topic

This reminded me, does EspoCRM have a more 'failsafe' solution? If it fail it should only fail in relation to BillRecord and nothing else such as Contact, Account, etc should still work rather than crashing the system altogether (assuming it is not linked to somehow to these Entity).

[Maximus]

Hi,
Unfortunately it is out of my system structure knowledge. You need to ask yuri about such behaviour.

[murugappan]

Hi Espcrm, I agree with you. But the architecture of the system is not based on "load-as-needed" instead it based on loading all at startup". So the system seems to collect all the items (modules and classes) at startup. It has its pros and cons. I guess it works fine with core modules but when it comes to custom modules it does not know which are core based and so loads up all. The thing that puzzles me is why this did not happen for all versions <= 5.9.4. I am still running version 5.9.4 with the "original" code. Hmmm...... Unfortunately, this happens in Joomla too. I hope they resolved in version 4.

I am going to hold off on Version 6.x. Patch releases are coming in too fast.