We were redirecting any logging happening via the Go standard logger
to our own mlog instance. The issue is that all those logs were happening
at LvlStdLog level which is higher than LvlDebug.
LvlStdLog is at 10, and LvlDebug is at 5. So unless a customer
sets the log level specifically to "stdlog" or sets up advanced
logging to specifically log for that level, no standard logs will
ever get logged.
We fix this by logging it at warn level. The reason for warn
is that mostly external libraries use this facility to log
out-of-band errors that could not be returned using standard
error returns.
I saw another plugin error which was logged similarly. This
was never surfaced before due to this bug.
https://mattermost.atlassian.net/browse/MM-62926
```release-note
NONE
```
We do a cluster request to get the active and dead queues
from other nodes in the cluster to sync any missing
information.
We check the dead queue in the other nodes to see
if there's been any message loss or not. Accordingly,
we send just the active queue or both active and dead queues.
There's still an edge case that is left out where
a client could have potentially connected and reconnected
to multiple nodes leaving multiple active queues
in multiple nodes. We don't handle this scenario
because then potentially we need to create
a slice of sendQueueSize * number_of_nodes. And then
this can happen again, leading to an infinite increase
in sendQueueSize.
We leave this edge-case to Redis, acknowledging
a limitation in our architecture.
In this PR, when there's no message loss, we just
take the active queue from the last node it connected
to.
And if there's message loss where the client's
seqNum is within the last node's dead queue, we also
handle that.
But if there's severe message loss where the client's
seqNum falls within the dead queue of another node, then
we just send the data from that node to reconstruct the
data as much as possible. It could be possible to set
a new connection ID in this case, but this involves
more data transfer always from all nodes and recomputing
the state in the requestor node.
https://mattermost.atlassian.net/browse/MM-61904
```release-note
NONE
```
Co-authored-by: Mattermost Build <build@mattermost.com>
* MM-62378: Initialize status and session cache before loading license
ps.LoadLicense could end up calling InvalidateAllCaches. Therefore,
we need to intialize those caches before calling LoadLicense
to prevent a panic from happening.
While here, we also remove some unused code.
https://mattermost.atlassian.net/browse/MM-62378
```release-note
NONE
```
* fix lint errors
```release-note
NONE
```
* fix test
```release-note
NONE
```
Drop the legacy `X` suffix from `GetMasterX` and `GetReplicaX`. The
presence of the suffix suggests there's a `non-X` version: but in fact
we migrated these away a long time ago, so remove the cognitive
overhead.
As an aside, this additionally helps avoid trip up LLMs that interpret
this as "something to fix".
We were incorrectly not broadcasting status cache updates
inspite of that being an LRU cache.
We were also not doing it for profilesInChannel cache.
Now we fix it by properly checking the invalidationEvent
which is something local to the cache itself rather
than the cache provider.
https://mattermost.atlassian.net/browse/MM-62077
```release-note
NONE
```
This introduces a new entry in the `Main Menu -> About` modal with the hostname of the currently connected websocket. This will be used to aid debugging issues in clustered environments by showing which node in the cluster is servicing requests for a particular websocket.
This information is only visible in self-managed instances. It will not be visible on cloud instances.
We don't clear the Redis cache for every test.
This can cause issues because the cache is shared
across test. We fix that with this PR.
```release-note
NONE
```
And re-order the server initialization (AGAIN).
For the nth time, we found several bugs in the initialization
process.
1. filestore.NewExportFileBackend and filestore.NewFileBackend
depended on license, but the license wasn't even loaded until
later!
2. The `ps.sqlStore.UpdateLicense` call also didn't work
because the license wouldn't get loaded. It only accidentally
worked because of `ps.AddLicenseListener` which would update
the license later on. We remove that.
Ideally, we would have loaded the license first and then
checked for redis client, but it's very difficult to do that.
Reasons are explained in the code comment.
So we just wait until the license is loaded, and simply throw an
error later.
https://mattermost.atlassian.net/browse/MM-61229
```release-note
NONE
```
---------
Co-authored-by: Mattermost Build <build@mattermost.com>
The Store variable was written to _after_ the server
started which was causing the race.
We simply move it to before we start the server.
While we are here, we fix yet another race condition
which was unrelated, but doing it in one sweep. This
was related to the user props access. When a user is updated,
there was 3 ws events that get sent out, 2 were deep-copied
whereas 1 was not. This led to race condition in postgres
binary-param mode where we were trying to set the user props.
https://mattermost.atlassian.net/browse/MM-61700
Tests at very high scale indicates that the iteration
of all connections during websocket broadcast starts
to become a bottleneck.
To optimize this, we move the channelMember cache from
inside web_conn.go to the hubConnectionIndex.
This involves adding a new map keyed by the channelID
and containing all webConns where the user is a member
of that channel. Subsequently, a new method needed to
be added to invalidate the cache which previously
used to happen in web_conn.
And as a last step, we remove the cache from web_conn
to reduce SQL queries to the DB.
https://mattermost.atlassian.net/browse/MM-61130
```release-note
NONE
```
This test actually tested that there is no race
_if_ session pooling is there. But there is no session pooling
any more so this test is irrelevant.
https://mattermost.atlassian.net/browse/MM-61225
```release-note
NONE
```
This originated from https://github.com/mattermost/mattermost/issues/15249.
However, the original idea was discarded https://github.com/mattermost/mattermost/issues/15249#issuecomment-709713065
as being too complicated to implement. Then I had another
idea to implement it just for session objects.
My thinking was that since every single request allocates a new
session struct, it would be good to use a sync.Pool for that.
However, 4 years later, now we know that the primary bottleneck
in app performance comes from websocket event marshalling.
Therefore, while it would be good to do this, it is difficult
to do it correctly (as shown by the numerous racy tests).
Hence, reverting this.
```release-note
NONE
```
We sprinkle a bit of generic magic to refactor a lot
of duplicate code.
To avoid exposing unnecessary code, I duplicated the function
twice. But let me know if you have strong opinions about this.
https://mattermost.atlassian.net/browse/MM-60171
```release-note
NONE
```
---------
Co-authored-by: Mattermost Build <build@mattermost.com>
On user login, we were aggressively clearing the channel member
cache when it wasn't necessary. There is no channel membership
info that is changing on a user login.
Additionally, we fix some more issues with pointer passing
to the cache. It's a known problem that our value passing
style isn't consistent when we fetch items from cache.
Sometimes we pass pointer-to-pointer, sometimes it's just a
pointer. This is also the reason for https://github.com/mattermost/mattermost/pull/27830.
We fix 2 such cases where we passed pointer-to-pointer
but didn't handle the special case inside the cache.
This time, we actually fix it in the app layer instead
of the cache layer and also add a test for good measure.
https://mattermost.atlassian.net/browse/MM-60480
```release-note
NONE
```
Co-authored-by: Mattermost Build <build@mattermost.com>
- Update library version.
- Added MaxFlush delay to help reduce CPU usage.
- Fall back to LRU cache for the caches which use SCAN.
- Added mattermost-redis and running for all api layer
tests in Postgres.
https://mattermost.atlassian.net/browse/MM-59934
```release-note
NONE
```
PR: https://github.com/mattermost/mattermost/pull/27204 fixed the issue
where `invalidateWebConnSessionCacheForUser` was not broadcasted across
the cluster. However, we became too conservative and started to invalidate
the session cache as well.
But the session cache only contains the session details for the user
and the team membership. There is no channel membership related info.
Therefore, we avoid that and improve performance as well.
https://mattermost.atlassian.net/browse/MM-60478
```release-note
NONE
```
Co-authored-by: Mattermost Build <build@mattermost.com>
* Adds status sync to shared channels
To allow for status to be synced, this changes add a new type of
shared channel internal task. This task has its contents pre-fetched
and stored in the `existingMsg` property, and it is keyed with a user
ID besides a channel ID, so it doesn't conflict with channel-driven
synchronization tasks.
All status synchronizations are triggered from the app layer, so there
is no need of watching for new WebSocket events. Although right now
we're only syncing one user status per message, the changes account
for a list of statuses in case we want to batch them in the future.
The feature is gated by a configuration property and can be disabled
independently of the rest of Shared Channels if it's necessary. It is
backwards compatible as well, and should cause no problems with
servers running older Mattermost versions.
* Adds status sync error management and retry
* Adds DisableSharedChannelsStatusSync to the telemetry report
---------
Co-authored-by: Mattermost Build <build@mattermost.com>
