Mattermost 7.2 に upgrade すると DM が表示できない(通常の channel や group message は表示できる)．環境は以下．
- self-hosted
- Debian GNU/Linux bullseye (11.4) amd64
- mariadb 1:10.5.15-0+deb11u1
Web appでも Desktop appでもだめで，Mobile appの場合は User を選択して，Send Message から DM を参照できる．
いろいろ探ってみたのだが API で /api/v4/users/me/teams/<team_id>/channels/categories (Sidebar 用の情報取得) を叩いた際に Direct Messages の Category が空になっていて，どうやら DM の Channel ID が取得できていない雰囲気．Mobile app でも確かに Sidebar 情報の DM の箇所が空になる．
直接 DM の Channel ID を指定して /api/v4/channels/<channel_id>/posts は，きちんと DM のやり取りを返すので，Channel (ID)まわりが怪しい．
Mattermost self-hosted changelog Release v7.2 - Feature Release によると 7.2 に upgrade する際に
ALTER TABLE Channels MODIFY COLUMN Type ENUM("D", "O", "G", "P");するらしい．backup をとっていたので，upgrade 前後で Channels table を比較すると，Type column の値がもとは D O G P といった 1文字だったところが，空になっている．なお，型については以下の通り変更されていた．
- before upgrade:
`Type` varchar(1) DEFAULT NULL - after upgrade:
`Type` enum('D','O','G','P') DEFAULT NULL
なんだか ALTER コマンドがうまく変換してくれないらしい．Type が空なので，
- O: public (open) channel
- P: private channel
- D: DM
- G: group message
の区別ができなくなって(https://github.com/mattermost/mattermost-server/blob/master/model/channel.go#L20)，DM の Channel ID が取得できなかったものと思われる．Backup から適当に sql を作成して，Type カラムの値を復元したら直った．
全然だれもこのバグの報告を forum とかでしていなくて，known issue にもなっていなくて，実はだれも Debian で self-hosted で Mattermost を運用していないのかしらと思ったり思わなかったり(Slack が 9/1 から無料プランだと90日間しか履歴が見れなくなったので(以前は期限なしで，ただし，10,000件までだった)，Mattermost も積極的にプレゼンスを上げようとしているはずなのだけど)．
以下備忘．
file=`date +%Y%m%d%H%M`
mysqldump -u root -p<PW> --all-databases --events | xz > $fileのように backup をとっていた．以下みたいな箇所を切り出してきて(backup はこのように，一旦 Table を削除して，再度作り直す SQL になっている)，
DROP TABLE IF EXISTS `Channels`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `Channels` (
`Id` varchar(26) NOT NULL,
`CreateAt` bigint(20) DEFAULT NULL,
`UpdateAt` bigint(20) DEFAULT NULL,
`DeleteAt` bigint(20) DEFAULT NULL,
`TeamId` varchar(26) DEFAULT NULL,
**snip**
) ENGINE=Mroonga DEFAULT CHARSET=utf8mb4;
/*!40101 SET character_set_client = @saved_cs_client */;
--
-- Dumping data for table `Channels`
--
LOCK TABLES `Channels` WRITE;
/*!40000 ALTER TABLE `Channels` DISABLE KEYS */;
INSERT INTO `Channels` VALUES (**snip**);
/*!40000 ALTER TABLE `Channels` ENABLE KEYS */;
UNLOCK TABLES;CREATE TABLE の箇所は upgrade 後のものを，INSERT INTO `Channels` VALUES の箇所は upgrade 前のものを利用するようにして，それを適当に from_backup.sql とかのファイル名で保存して，あとは以下のように実行するのみ．もちろん Mattermost は停止しておく．
% mysql -u <mattermost_db username> -p<mattermost_db_password>
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 2965
Server version: 10.5.15-MariaDB-0+deb11u1 Debian 11
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> use mattermost;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
MariaDB [mattermost]> source from_backup.sqlなお，API 叩く(テストする)のに以下のような script を作っておくと便利(.token というファイルを用意しておいて Personal Access Tokens を入れておく)．
#!/bin/sh
curl -H "Authorization: Bearer $(cat .token)" https://mattermost.example.org/$1 | jq./a.sh だとして % ./a.sh /api/v4/users/me のように使う．GET しかできないけど，問題を追うにはこれで充分だった．
/api/v4 も書かせる仕様にしてあるのは，config.json で LogSettings の FileLevel を DEBUG にした際の mattermost.log に出力される API endpoint の表記が /api/v4 を含んでいたため．% tail -f mattermost.log | grep GET | sed 's,.*"url":"\([^"]*\)".*,\1,' とかで，どの API が叩かれているかを追っていた．