Adding tags to thread silently fails if the xf_tag_content table has exhausted it's ids

X

Xon

Well-known member
Affected version
2.2.15
This was exasperated by a custom addon miss-behaving (constantly adding & removing tags), and a mariadb 10.6.x galera cluster which increments ids by 3 every insert,

I'm not sure if this is a php bug for why it didn't hit 2^32 or what, but addTagIdsToContent was just silently failing when the table had the following autoincrement id of 4280404161.

\XF::db()->insert() was returning a falsy value after the insert failed, and the mysql error/warning was swallowed somewhere.

Schema snippet
SQL: 
CREATE TABLE `xf_tag_content_broken` (
  `tag_content_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `content_type` varbinary(25) NOT NULL,
  `content_id` int(10) unsigned NOT NULL,
  `tag_id` int(10) unsigned NOT NULL,
  `add_user_id` int(10) unsigned NOT NULL,
  `add_date` int(10) unsigned NOT NULL,
  `visible` tinyint(3) unsigned NOT NULL,
  `content_date` int(10) unsigned NOT NULL,
  PRIMARY KEY (`tag_content_id`),
  UNIQUE KEY `content_type_id_tag` (`content_type`,`content_id`,`tag_id`),
  KEY `tag_id_content_date` (`tag_id`,`content_date`),
  KEY `add_user_id` (`add_user_id`)
) ENGINE=InnoDB AUTO_INCREMENT=4280404161 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci

Thankfully tag_content_id isn't actually used anywhere, so I was able to re-compact the ids with the following SQL:

SQL: 
rename table xf_tag_content to xf_tag_content_broken;
create table xf_tag_content like xf_tag_content_broken;
insert into xf_tag_content (content_type,content_id,tag_id,add_user_id,add_date,visible,content_date)
select content_type,content_id,tag_id,add_user_id,add_date,visible,content_date
from xf_tag_content_broken;

Once I had done that, adding tags worked fine
 
Back
Top Bottom