Self Hosted Issue When Updating to v5.3.86 - Endless spinning wheel at the log in page

Self-Hosted | v5
#1

Environment: Production Invoice Ninja Self Hosted - version 5.3.81 being upgraded from the self update web console to v5.3.86
OS - Debian 10 server with current security patches (Linux)
PHP - v8.0.18 with current security patches
DataBase Engine - MySQL/MariaDB - Current version with latest security patches
Web Server - Apache v2.4.52 with current security patches
PDF Engine - Local SnapPDF (not using Phantom)
Other - Virtual Machine = yes
Other - VM is not Docker; private VM instance with dedicated resources

Error and Issue: Upgrading Invoice Ninja from v5.3.81 to v5.3.86 via the self update within the web application console. After the update is completed the webpage reloads and displays spinning wheel and never passes this point.

Questions: Seem to recall seeing something in release notes a few days ago that a recent update affected the database with an expansion of certain field data entries and contained other major changes.
Could these changes be the source of the issue?
Are there pre and/or post tasks that need to be completed in addition to the routine application update?

Thanks in advance for your help on this issue

#2

Hi,

Are there any errors in storage/logs?

#3

Logs

/var/log/apache2/error.log

cannot add scalar value without an associated key

/var/www/html/invoiceninja/storage/logs/laravel.log

        document.querySelectorAll('#statement-invoice-table > thead > tr > th, #statement-payment-table > thead > tr > th, #statement-aging-table > thead > tr > th').forEach(t => {
            t.hidden = false;
        });
    </script><script>document.addEventListener("DOMContentLoaded",function(){document.querySelectorAll("#product-table > tbody > tr > td, #task-table > tbody > tr > td, #delivery-note-table > tbody > tr > td").forEach(t=>{if(""!==t.innerText){let e=t.getAttribute("data-ref").slice(0,-3);document.querySelector(`th[data-ref="${e}-th"]`).removeAttribute("hidden")}}),document.querySelectorAll("#product-table > tbody > tr > td, #task-table > tbody > tr > td, #delivery-note-table > tbody > tr > td").forEach(t=>{let e=t.getAttribute("data-ref").slice(0,-3);(e=document.querySelector(`th[data-ref="${e}-th"]`)).hasAttribute("hidden")&&""==t.innerText&&t.setAttribute("hidden","true")})},!1);</script><script>document.addEventListener("DOMContentLoaded",function(){document.querySelectorAll(`[data-state="encoded-html"]`).forEach(e=>e.innerHTML=e.innerText)},!1);</script></div></div></body></html>

also in /var/www/html/invoiceninja/storage/logs/laravel.log

[2022-05-09 06:00:02] production.INFO: Performing Autobilling 2022-05-09 06:00:02
[2022-05-10 00:00:03] production.INFO: updating currencies
[2022-05-10 06:00:01] production.INFO: Performing Autobilling 2022-05-10 06:00:01
[2022-05-11 00:00:03] production.INFO: updating currencies
[2022-05-11 06:00:02] production.INFO: Performing Autobilling 2022-05-11 06:00:0

Nothing is really jumping out at me. Maybe you see something I don’t

#4

Looks like the error message

cannot add scalar value without an associated key

is something related to the WAF. We will forward this to the our internal security config guys to see what they can make of it. That being said, I suspect there is an task sequence upgrade to the DB table or something during the update that digs into the data, metadata and\or schema that may be causing this. The WAF may be interfering with this item and is incorrectly detected an intrusion or SQL injection attack.

All that being said, it looks like the issue may be on our side. More to come as we get info.

#5

Selection_034
Selection_034641×602 32.8 KB

Cleared the cache on the web browser and reloaded the website. Now we get the log in page but there is an error

Message: Error :: ‘[language_id, 1, currency_id, 1, payment_terms, 30, valid_until, 30, default_…’ to ‘minified:vn’ failed due to: Deserializing ‘30’ to ‘String’ failed due to: TypeError: 30: type ‘minified:a2R’ is not a subtype of type 'String’

#6

Workaround: The issue is NOT related to our WAF. We were able to work around the issue by rolling back the VM to an earlier snapshot (approx 1 month ago) and then updating from 5.3.78 to the current v5.3.86 update. Before this was done, we dumped the database, preformed the update and then reimported the database dump to bring all the info current.

Not sure what happened but the affected VM will be handed over for a deeper forensic analysis. Really weird…

If we find anything worth sharing we will follow up. Thanks

1 Like