Unable to post attachments after upgrade

Troubleshooting
1

Summary
After upgrading to 5.33.3, unable to attach any files to a post.

Steps to reproduce
Server 5.33.3. Tried with desktop app 4.5.2 or 4.6.2, or with Chrome, on mac.

Observed behavior
Attempting to attach any file to a post (using the attachment button and file selector, or copy-pasting an image) results in:

  • Red error “Unable to save the file info.” below the post
  • Errors like the following in the server log
2021-04-25T20:12:10.365+1000	error	mlog/log.go:232	Unable to save the file info.	{"path": "/api/v4/files", "request_id": "7chdxz7fwtfd9x5ehq8gnrmjsc", "ip_addr": "10.64.244.69", "user_id": "y68mtriszf85zg48mbxto3gcac", "method": "POST", "err_where": "UploadFileX", "http_code": 500, "err_details": "failed to save FileInfo: Error 1022: Can't write; duplicate key in table 'FileInfo'"}
2

This is quite bad actually - users will be unable to post attachments and I am not keen on trying to roll back.

I realise that the core error duplicate key in table is coming from our mysql database (actually Amazon Aurora). The FileInfo table has this create definition:

CREATE TABLE `FileInfo` (
  `Id` varchar(26) NOT NULL,
  `CreatorId` varchar(26) DEFAULT NULL,
  `PostId` varchar(26) DEFAULT NULL,
  `CreateAt` bigint(20) DEFAULT NULL,
  `UpdateAt` bigint(20) DEFAULT NULL,
  `DeleteAt` bigint(20) DEFAULT NULL,
  `Path` text,
  `ThumbnailPath` text,
  `PreviewPath` text,
  `Name` text,
  `Extension` varchar(64) DEFAULT NULL,
  `Size` bigint(20) DEFAULT NULL,
  `MimeType` text,
  `Width` int(11) DEFAULT NULL,
  `Height` int(11) DEFAULT NULL,
  `HasPreviewImage` tinyint(1) DEFAULT NULL,
  `MiniPreview` mediumblob,
  `Content` longtext,
  PRIMARY KEY (`Id`),
  KEY `idx_fileinfo_update_at` (`UpdateAt`),
  KEY `idx_fileinfo_create_at` (`CreateAt`),
  KEY `idx_fileinfo_delete_at` (`DeleteAt`),
  KEY `idx_fileinfo_postid_at` (`PostId`),
  KEY `idx_fileinfo_extension_at` (`Extension`),
  FULLTEXT KEY `idx_fileinfo_name_txt` (`Name`),
  FULLTEXT KEY `idx_fileinfo_content_txt` (`Content`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

I am not sure how we got into this state after the upgrade.

3

Confirmed that any insert into FileInfo results in the same error. The table seems to be in an unusable state.

I think I fixed this by doing the following (after stopping server):

mysqldump ... mattermost FileInfo > FileInfo.dump
mysql ... mattermost < FileInfo.dump

Since this drops and recreates the table with the same content, I was hoping it would replace whatever bad table definition was in there. Seemed to work.

4

I had the exact same issue, and your fix worked for me gubbins. Thank you!