Yeah I can setup an environment for debugging, there is a backup of the exact moment where the upgrade process got stuck. I'll set that up later this weekend and update the support ticket.
A very radical fix for me was:
Drop xf_purchase_request table
Run the cmd.php xf:repair-db command which recreate the table
This will continue the install process, but all the data in that table is lost, what does this have as consequences?
Despite running the query and having the latest version manually uploaded and deployed, I still get the error?
I already have data in the provider_metadata columns, not sure if that's an issue?
I had this issue today as well when upgrading from Ubuntu 20 LTS to 22.
PHP updated to 8.1 and Mariadb updated to 10.6.7.
For some weird reason, the collation of all the tables went to utf8mb3 and running the cmd.php xf:convert-utf8mb4 had no effect and returned that no convertable tables were...
It seems the issue is related to the automatic bounce handler.
I was using an email address set as default for board notifications, and I set up an email address dedicated to just bounced mails (as indicated in the instructions).
When I disabled the automatic bounce handler, the errors stopped...
Not sure how to do that on Safari, but in Firefox/Chrome you can enable a 'Developer Mode' to see the network requests or javascript errors when loading the page. This could help you get a better idea of what the problem is. 'Protocol error' is pretty vague. (http2? ssl? udp/tcp?)
Interestingly enough, once the table was recreated and I checked a few hours later, the mail queue had already thousands of mails waiting in the queue. All the mails in the queue were destined to the same user (using a @gmail.com account). There seems to be a logic loop somewhere that keeps...
For posterity, I was able to view and copy the blank table from a previous backup. In order to recreate the xf_mail_queue table, the following sql query has to be run:
SET NAMES utf8;
SET time_zone = '+00:00';
SET foreign_key_checks = 0;
SET sql_mode = 'NO_AUTO_VALUE_ON_ZERO';
DROP TABLE IF...
Hello, recently I noticed the VPS we use for our forums crashed and upon investigation the system had no disk space whatsoever. xf_mail_queue somehow used all the remaining disk space and caused mariadb to crash and the webserver.
I couldn't truncate the xf_mail_queue table as that requires the...
It seems the issue returned, I assumed it worked since the errors were not appearing anymore.
I tried reinstalling Sendmail but that didnt work, and I also tried Postfix, but I keep getting errors 'Unable to send mail'.
edit: It also looks like there are only 2 users who are generating a...