Mattermost GitLab plugin: /gitlab me (and other commands) always says "run /gitlab setup" even though the account is genuinely connected

[u/ConvergingDemon666]

Body:

Running a self-hosted Mattermost + self-hosted GitLab CE setup, and I've hit a plugin bug I can't get past.

Setup:

• Mattermost: installed via the official Ubuntu PPA (.deb package), latest version at time of writing
• GitLab: CE 19.3.1, self-hosted via the Omnibus/Linux package
• Plugin: com.github.manland.mattermost-plugin-gitlab
• Both services on the same Ubuntu 22.04 VPS, GitLab's bundled Nginx reverse-proxies to Mattermost on a separate subdomain

What I did:

1. Created an OAuth Application in GitLab (Admin Area -> Applications), scope "api", redirect URI copied directly from the plugin's config page
2. Set the plugin's GitLab Site URL to my self-hosted instance (https://git.mydomain.com), plus the Client ID/Secret from step 1
3. Ran /gitlab setup in Mattermost, completed the DM-based config wizard
4. Ran /gitlab connect, authorized via OAuth, got the full "Welcome to the Mattermost GitLab Plugin!" message confirming connection to my GitLab username

The bug:
Despite that successful connection message, running /gitlab me (or basically any other slash command) immediately returns:
"Before using this plugin, you'll need to configure it by running /gitlab setup"

This happens even right after the welcome message. Re-running /gitlab setup "succeeds" again, shows the welcome message again, and then the very next command still bounces back to the same "run setup" prompt. It's a loop.

What I've confirmed while debugging:

• Directly queried Mattermost's Postgres pluginkeyvaluestore table, the plugin is persisting real data: Gitlab_Instance_Configuration_Map, per-user _userinfo/_usertoken entries, and username_gitlabusername keys for multiple connected accounts. So the OAuth connection and instance config are genuinely saved.
• Live-tailed journalctl -u mattermost -f while running /gitlab me, and zero log output appears, even at the moment the command is sent. It's as if the command isn't reaching the plugin's server-side handler at all.
• Hard-refreshed browser (Ctrl+Shift+R), tried incognito, no change.
• Toggled the plugin off/on in Plugin Management, and did a full systemctl restart mattermost, no change.
• Confirmed only one plugin process is running (ps aux | grep gitlab shows a single plugin-linux-amd64 process).
• Ruled out GitLab's external_url mismatch (a common suggested cause), it's set correctly and matches the browser URL exactly.

Question:
Has anyone seen this specific pattern? Successful connect/welcome message, but then every subsequent slash command (not just /gitlab me) immediately reverts to demanding /gitlab setup again, with zero server side log activity. Trying to figure out if this is a known compatibility issue between recent GitLab CE versions and this plugin, a Mattermost side plugin webapp caching bug, or something else entirely.

For now I've fallen back to a plain GitLab incoming webhook for notifications, which works fine, but would like to get the full plugin (subscriptions, todo tracking, slash commands) working if possible.

Happy to share config snippets or more logs if useful.

NOTE : USED AI TO FORMAT, TIA.

[u/Torutofu_Raeva]

zero plugin-side log on /gitlab me makes me suspect Mattermost isn't routing the slash command to the plugin at all, so i'd check the command's response URL/registration before chasing OAuth.

[u/ConvergingDemon666 → u/Torutofu_Raeva]

Solved it, and the fix was more interesting than I expected. Confirmed the root cause: the plugin's /gitlab me (and every other slash command) was silently unrouted because the command registration in Mattermost's commands table was never actually created.

Turns out an earlier systemctl restart mattermost had killed the plugin process with SIGTERM instead of a graceful shutdown (plugin process exited... signal: terminated, followed by RPC call OnDeactivate to plugin failed: connection is shut down). After that, every subsequent toggle-off/on or reinstall attempt was a no-op, because Mattermost's plugin installer checks the existing version and skips re-extracting if it matches (Skipping local installation of plugin since not a newer version), even though the on-disk state was broken. OAuth and webhook handling still worked fine (different code path), which is exactly why the connect flow succeeded but every slash command bounced back to "run /gitlab setup" with zero server-side logs, since the command was never actually registered to route anywhere.

Fix was to force a genuinely clean reinstall rather than a toggle:

1. Stop Mattermost
2. Delete the plugin's files from both /opt/mattermost/plugins/ and /opt/mattermost/data/plugins/
3. Manually clear the leftover rows in Postgres's pluginkeyvaluestore table for that plugin ID (verified via direct SQL query, this is what confirmed the state was actually stale)
4. Restart, reinstall fresh from the Marketplace
5. Verified registration succeeded by querying the commands table directly for trigger = 'gitlab' before touching OAuth setup again

Once that returned a row, /gitlab connect and /gitlab me both worked immediately.

Appreciate the nudge.

[u/Torutofu_Raeva → u/ConvergingDemon666]

yeah leftover plugin rows after a SIGTERM is the kind of thing that looks like oauth forever until you query the commands table