A deadlock that has been found on our Community servers is:
```
------------------------
LATEST DETECTED DEADLOCK
------------------------
2022-03-03 06:14:37 0x2aec58887700
*** (1) TRANSACTION:
TRANSACTION 1043681684, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 23 lock struct(s), heap size 1136, 137 row lock(s), undo log entries 26
MySQL thread id 448011, OS thread handle 47195956565760, query id 752406931 10.128.147.211 mmcloud updating
DELETE FROM SidebarChannels WHERE ((ChannelId IN (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) OR ChannelId IN (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)) AND CategoryId = ?)
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 907 page no 368 n bits 0 index PRIMARY of table `mattermost`.`SidebarChannels` trx id 1043681684 lock_mode X waiting
Record lock, heap no 121 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
0: len=26; bufptr=0x2aebbd36b75c; hex= 3363776f6a6a6d36316a62663967657036706872316533696a77; asc 3cwojjm61jbf9gep6phr1e3ijw;;
1: len=26; bufptr=0x2aebbd36b776; hex= 3568616279726d36746a6265747061656538786973786d6b7177; asc 5habyrm6tjbetpaee8xisxmkqw;;
2: len=26; bufptr=0x2aebbd36b790; hex= 373568726a7a68676169726370653477696877727866716f7463; asc 75hrjzhgaircpe4wihwrxfqotc;;
3: len=6; bufptr=0x2aebbd36b7aa; hex= 00003e355176; asc >5Qv;;
4: len=7; bufptr=0x2aebbd36b7b0; hex= 39000352420fce; asc 9 RB ;;
5: len=8; bufptr=0x2aebbd36b7b7; hex= 80000000000000fa; asc ;;
*** (2) TRANSACTION:
TRANSACTION 1043681679, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 76 lock struct(s), heap size 1136, 294 row lock(s), undo log entries 72
MySQL thread id 447990, OS thread handle 47194812454656, query id 752406930 10.128.147.211 mmcloud updating
DELETE FROM SidebarChannels WHERE ((ChannelId IN (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) OR ChannelId IN (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)) AND CategoryId = ?)
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 907 page no 368 n bits 0 index PRIMARY of table `mattermost`.`SidebarChannels` trx id 1043681679 lock_mode X
Record lock, heap no 121 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
0: len=26; bufptr=0x2aebbd36b75c; hex= 3363776f6a6a6d36316a62663967657036706872316533696a77; asc 3cwojjm61jbf9gep6phr1e3ijw;;
1: len=26; bufptr=0x2aebbd36b776; hex= 3568616279726d36746a6265747061656538786973786d6b7177; asc 5habyrm6tjbetpaee8xisxmkqw;;
2: len=26; bufptr=0x2aebbd36b790; hex= 373568726a7a68676169726370653477696877727866716f7463; asc 75hrjzhgaircpe4wihwrxfqotc;;
3: len=6; bufptr=0x2aebbd36b7aa; hex= 00003e355176; asc >5Qv;;
4: len=7; bufptr=0x2aebbd36b7b0; hex= 39000352420fce; asc 9 RB ;;
5: len=8; bufptr=0x2aebbd36b7b7; hex= 80000000000000fa; asc ;;
[bitmap of 256 bytes in hex: 00 00 00 00 00 00 00 f0 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ]
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 907 page no 67 n bits 0 index PRIMARY of table `mattermost`.`SidebarChannels` trx id 1043681679 lock_mode X waiting
Record lock, heap no 103 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
0: len=26; bufptr=0x2aeb4515ec1b; hex= 6431376b35706f71786979776d6b6d616b6a78623539356b366f; asc d17k5poqxiywmkmakjxb595k6o;;
1: len=26; bufptr=0x2aeb4515ec35; hex= 7067653939686a356562676b38636f6f70637a6e7871677a6568; asc pge99hj5ebgk8coopcznxqgzeh;;
2: len=26; bufptr=0x2aeb4515ec4f; hex= 336e3731636a73656f667931397267746664337962786d713777; asc 3n71cjseofy19rgtfd3ybxmq7w;;
3: len=6; bufptr=0x2aeb4515ec69; hex= 00003e34fa4d; asc >4 M;;
4: len=7; bufptr=0x2aeb4515ec6f; hex= 4600026d940e4c; asc F m L;;
5: len=8; bufptr=0x2aeb4515ec76; hex= 8000000000000082; asc ;;
*** WE ROLL BACK TRANSACTION (1)
```
It seems like 2 DELETE queries are somehow deadlocking on the same row.
On looking at it deeply, we can see that in an updateSidebarCategory scenario,
we run 2 delete queries in a single transaction. In that delete query, we not only delete the existing channels for a category,
but also delete the new channels that are going to be inserted in the new category.
The potential issue with this is that since we are updating both the source and destination category in a single transaction,
the category which is moved appears in the destination section for the first category, and in the source section for the second category.
Which means in a single transaction, you have 2 queries possibly interlocking due to the same channels.
Therefore, if we run 2 separate updateCategories with an inverted order of categories, then the same set of delete queries
can lock on the opposite order of channels and cause a deadlock.
I haven't been able to reproduce this, but just a hunch. And in any case, this will reduce the number of DB updates.
```release-note
NONE
```
Co-authored-by: Mattermod <mattermod@users.noreply.github.com>
* Added Archived column to FileInfo
* fixed typo
* Added new column to store column list
* Fixing tests
* Updated migration number to syncup with master
* MM-38982: fixes SVG uploading
Uploading SVG files was "almost" treated like an image in some places,
resulting in not showing the SVG on the client.
This is happening because when we fail to generate a mini preview for an
image, we prepend "invalid-" to the MimeType.
This commit adds a check to guard against SVG files in methods that make
no sense for SVGs.
* Reverts invalid-{mimetype} fix
* Uses fileInfo.IsSvg() where it can
* MM-43529 - start freemium trial
* change the method to put
* Add unit testing for the request-trial-endpoint
* use correct require
* add the translation texts
* fix texts
* remove unnecessary log
* change response status code to forbidden when non cloud
Co-authored-by: Pablo Velez Vidal <pablo.velez@mattermost.com>
We move away with the update logic and just set an empty
slice always.
```release-note
The value of ServiceSettings.TrustedProxyIPHeader will default
to empty from now on. A previous bug prevented this from happening
in certain conditions. Customers are requested to check for these
values in their config and set them to nil if necessary.
```
Just a quick POC to move fast :P
We use a search pointer to keep track of
the next row to inesrt to. For every new search
we increment the pointer and do modulo 5.
This means that the value will always remain
between 0-4. And that way, we will always overwrite
the oldest entry on every search.
And while getting the results, we get
all results for that user.
The search parameters are json marshalled
and stored as a JSON blob. This is because
there is no need to search/filter them
in the DB.
Pending items:
Tests obviously.
To improve:
The client needs to send the channel ids
instead of channel names.
