mirror of
https://github.com/mattermost/mattermost.git
synced 2026-09-21 14:20:41 +08:00
* MM-68622: start inter-cluster services before plugin activation
Move startInterClusterServices from the end of Server.Start() to the
beginning, before Channels().Start() initializes plugins. This lets
plugins call shared channels APIs (ShareChannel, InviteRemoteToChannel,
UninviteRemoteFromChannel, UnshareChannel, UpdateSharedChannel,
CheckCanInviteToSharedChannel) during OnActivate instead of failing with
"Shared Channels Service is disabled".
Side-effect analysis:
* Plugin API gating: getSharedChannelsService in
channels/app/shared_channel.go:32 only requires the service to be
non-nil. The plugin-facing wrappers all pass ensureIsActive=false, so
Active() is bypassed. Once SetSharedChannelService runs, calls succeed
on both leader and follower nodes. This is the fix path.
* Multi-node leader timing: the enterprise cluster impl in
enterprise/cluster/cluster.go:70 initializes currentLeader="", so
IsLeader() returns false before StartInterNodeCommunication runs. The
immediate onClusterLeaderChange in scs.Start at
platform/services/sharedchannel/service.go:151 therefore takes the
pause path, which is a no-op since the service was never active. When
memberlist.Create fires NotifyJoin for the local node,
addPotentialLeader runs and InvokeClusterLeaderChangedListeners drives
the registered listener to resume() the sync loop on the elected
leader. End state matches the prior ordering.
* Single-node: IsLeader() returns true unconditionally per
channels/app/platform/cluster.go:33, so SharedChannelSyncHandler is
active during plugin OnActivate. Events emitted by plugins during
activation (posts to shared channels, DM creation) now flow through
sync where they were previously dropped. This is intended correctness,
not a regression.
* Transport and handlers: api4 remote-cluster routes are registered
before Server.Start, so HTTP handlers exist when rcs.Start runs early.
rcs and scs do not send cluster-broadcast messages during Start; they
only register topic listeners on the rcs transport, which is
independent of cluster gossip. registerClusterHandlers ordering is
unaffected.
* Config: scs reads only ConnectedWorkspacesSettings and the License at
construction, both stable from the initial config load. ReloadConfig
at server.go:912 has no bearing on inter-cluster service init.
Errors from startInterClusterServices remain logged and non-fatal,
matching prior behavior.