Upgrade database error - OJS 2.4.8 to 3.1.1 - PKPSubmissionFileDAO assertion

I’m attempting to update OJS from 2.4.8 to 3.1.1, and the upgrade is failing with the informative “Invalid File!” message on screen.

I’m hoping to get some assistance figure out the cause of the failure. The apache error_log file on my server ends with the following warnings and errors:

PHP Warning: Cannot use a scalar value as an array in /home/arccjour/public_html/arcc-upgrade/lib/pkp/classes/core/DataObject.inc.php on line 133, referer: https://www.arcc-journal.org/arcc-upgrade/index.php/index/install/upgrade
WARNING: Unable to find a match for "443-1509-3-RV.doc" in "/home/arccjour/arcc-upgrade-files/journals/1//articles/443/". Skipping this file., referer: https://www.arcc-journal.org/arcc-upgrade/index.php/index/install/upgrade
WARNING: Unable to find a match for "443-1509-2-RV.doc" in "/home/arccjour/arcc-upgrade-files/journals/1//articles/443/". Skipping this file., referer: https://www.arcc-journal.org/arcc-upgrade/index.php/index/install/upgrade
WARNING: Unable to find a match for "443-1521-3-ED.doc" in "/home/arccjour/arcc-upgrade-files/journals/1//articles/443/". Skipping this file., referer: https://www.arcc-journal.org/arcc-upgrade/index.php/index/install/upgrade
WARNING: Unable to find a match for "443-1521-2-ED.doc" in "/home/arccjour/arcc-upgrade-files/journals/1//articles/443/". Skipping this file., referer: https://www.arcc-journal.org/arcc-upgrade/index.php/index/install/upgrade
WARNING: Unable to find a match for "443-1521-1-ED.doc" in "/home/arccjour/arcc-upgrade-files/journals/1//articles/443/". Skipping this file., referer: https://www.arcc-journal.org/arcc-upgrade/index.php/index/install/upgrade
WARNING: Unable to find a match for "447-1519-1-SM.docx" in "/home/arccjour/arcc-upgrade-files/journals/1//articles/447/". Skipping this file., referer: https://www.arcc-journal.org/arcc-upgrade/index.php/index/install/upgrade
WARNING: Unable to find a match for "447-1520-1-RV.docx" in "/home/arccjour/arcc-upgrade-files/journals/1//articles/447/". Skipping this file., referer: https://www.arcc-journal.org/arcc-upgrade/index.php/index/install/upgrade
PHP Warning: assert(): Assertion failed in /home/arccjour/public_html/arcc-upgrade/lib/pkp/classes/submission/PKPSubmissionFileDAO.inc.php on line 285, referer: https://www.arcc-journal.org/arcc-upgrade/index.php/index/install/upgrade
ojs2: Invalid file!, referer: https://www.arcc-journal.org/arcc-upgrade/index.php/index/install/upgrade

First of all, is there anywhere else besides the error_log to investigate upgrade failures?

I’m assuming the missing file warnings aren’t a big problem since the upgrade moves on past several of them.

The assertion in PKPSubmissionFileDAO.inc.php is in the getLatestRevisionNumber method, and appears to be the result of a zero value revision being retrieved from the submission_files table.

Any idea why this would happen? Any approach to identifying which submission file was having it’s revision number retrieved when this occurred?

I’ve been diligent about resetting my uploaded files directory and 2.4.8 database before attempting to re-execute the upgrade, and hopeful an OJS upgrade veteran out there may have some insight for me about troubleshooting my upgrade failure.

Thanks!

Do not know other places to look except the error_log in this case.

Guessing it dies here: pkp-lib/PKPSubmissionFileDAO.inc.php at ojs-stable-3_1_1 · pkp/pkp-lib · GitHub

What comes to mind is that you could check from the pre-upgrade OJS2 database the submission_files table if the revision field and the fileId field has only numeric values. I mean I guess the code I linked above will return die if the value is null somewhere for some reason and the assertion failure suggest that this could be so with the revision field somewhere.

Buenas tardes, al actualizar la base de datos de OJS 2.4.8-3 a la versión 3.1.1-2 utilizando la linea de comandos en Debian 9 con php 7 me muestra los siguientes errores y no actualiza la base de datos
PHP Warning: Declaration of PKPUsageEventPlugin::getEnabled() should be compatible with LazyLoadPlugin::getEnabled($contextId = NULL) in /var/www/html/publicaciones/lib/pkp/plugins/generic/usageEvent/PKPUsageEventPlugin.inc.php on line 386
PHP Notice: Use of undefined constant MYSQL_BOTH - assumed ‘MYSQL_BOTH’ in /var/www/html/publicaciones/lib/pkp/lib/adodb/drivers/adodb-mysql.inc.php on line 718
ERROR: Upgrade failed: DB:

anteriormente tuve que actualizar algunas funciones de php ya que no estaban disponibles para php 7 en el archivo /var/www/html/publicaciones/lib/pkp/lib/adodb/drivers/adodb-mysql.inc.php:

MODIFIQUE LA mysql_pconnect por mysqli_connect en linea 475 y 477
MODIFIQUE @mysql_error por @mysqli_error en la linea 608
MODIFIQUE @mysql_query por @mysqli_query en la linea 599
MODIFIQUE @mysql_errno por @mysqli_errno en la linea 617 y 618
MODIFIQUE @mysql_free_result por @mysqli_free_result en la linea 801
MODIFIQUE @mysql_fetch_array por @mysqli_fetch_array en la linea 796.
Si podrían orientarme con el error, muchas gracias, saludos
Marcela

PHP Warning: Declaration of PKPUsageEventPlugin::getEnabled() should be compatible with LazyLoadPlugin::getEnabled($contextId = NULL) in /var/www/html/publicaciones/lib/pkp/plugins/generic/usageEvent/PKPUsageEventPlugin.inc.php on line 386

This comment seems unrelated to my original issue, and should probably be submitted as it’s own topic.

Guessing it dies here: https://github.com/pkp/pkp-lib/blob/ojs-stable-3_1_1/classes/submission/PKPSubmissionFileDAO.inc.php#L450 1

What comes to mind is that you could check from the pre-upgrade OJS2 database the submission_files table if the revision field and the fileId field has only numeric values. I mean I guess the code I linked above will return die if the value is null somewhere for some reason and the assertion failure suggest that this could be so with the revision field somewhere.

The line number for the assertion in PKPSubmissionFileDAO.inc.php was included in the error. It’s line 285, which is in the “getLatestRevisionNumber” method as I mentioned above. This assert fires when the retrieved revision value for a file is not > zero.

My 2.4.8 database does not include a submission_files table. It appears this table is created as a part of the database upgrade to version 3.1. All of the entries in my partially upgraded submission_files table are integers that are greater than zero, so I’m confused how the getLatestRevisionNumber method is failing.

Any idea where the submission file information is stored in the 2.4.x database? I would check there to see if there are any files with bogus version numbers, but I can’t find an obvious place to look for this in the databse.

Stuck on this problem, and hopeful I can get some help from other OJS users out there. Let me know if you have any ideas how to solve this problem so I can move forward with my upgrade to OJS 3.1.

After further investigation I’ve found that the article_files table in the 2.4.x database appears to have the same file entries that are in the submission_files table of the 3.1 database.

I’m not seeing any entries in the original article_files table that have non-numeric versions, so still unsure what is causing the getLatestRevisionNumber call to fail.

Ah yes, forgot about the renamed table. It has been so long since I worked with OJS2.

I am fairly sure that the warning you get from the failed assertion is not the reason the script dies. But it is probably caused by the same revision value that causes assignRevisionToReviewRound to return the fatal error because of the !is_numeric($revision) check there. That will output the “Invalid file!” text you have there in the last line.

One way of going forward is to add something like error_log(print_r($fileId, true)); just before this line: pkp-lib/PKPSubmissionFileDAO.inc.php at ojs-stable-3_1_1 · pkp/pkp-lib · GitHub.

That could give a hint on what file_id/revision is causing the problem. Of course if you have a lot of files, there will be a lot of output in the error_log. Alternatively, you could re-run the upgrade script, let it fail and then check from the created submission_files if there is a problematic value for the revision field.

How it gets there, not sure, but knowing what file_id is is connected might help solve the problem.

you can try the solution that bozana give me… please refer to my thread…

Buen día, disculpas, ya hice la consulta en un tema nuevo, saludos.
Marcela

It turned out that the solution mohd_arshad recommended worked to solve the problem I was having that resulted in the PKPSubmissionFileDAO assertion.

Once I patched this file I was able to complete a successful execution of the database upgrade.

Thanks for your help on this issue!