GitLab Plugin v1.12 Upgrade Leaves Existing Instances Without Migrated OAuth Configuration

Applies to: Mattermost Server with mattermost-plugin-gitlab upgraded from a pre-v1.12 version to v1.12.0 or v1.12.1

Symptoms: After upgrading the GitLab plugin to v1.12.0/v1.12.1, /gitlab connect fails and /gitlab instance list errors because existing OAuth credentials were never migrated into the new instance-configuration storage format.

🛑 Problem

A change in v1.12.0/v1.12.1 of the GitLab plugin altered how instance configuration is stored, but the upgrade did not migrate existing OAuth credentials into the new format. Servers that had the plugin installed prior to v1.12 end up with empty Gitlab_Instance_Configuration_Map and Gitlab_Instance_Configuration_Name_List keys in the plugin KV store, so the new code path that expects an instance name returns an error. v1.12.2 fixes this by removing the default instance setting requirement and falling back to the legacy config values.

Symptoms

/gitlab connect prompts for an instance name
/gitlab instance list returns an error

Additional symptoms:

• New users cannot complete the OAuth handshake to GitLab
• Existing connected users continue to work normally
• The following query against the Mattermost database returns zero rows on the affected server:

SELECT pkey, encode(pvalue, 'escape') AS value, expireat
FROM pluginkeyvaluestore
WHERE pluginid = 'com.github.manland.mattermost-plugin-gitlab'
  AND pkey IN ('Gitlab_Instance_Configuration_Map', 'Gitlab_Instance_Configuration_Name_List');

✅ Solution

The clean fix is to upgrade the GitLab plugin to v1.12.2 or later. That release removes the requirement to provide an instance name to /gitlab connect and falls back to the legacy config values, so new users can complete the OAuth flow without any KV-store seeding.

Upgrade the GitLab plugin to v1.12.2

1. Navigate to System Console > Plugin Management.
2. Upload mattermost-plugin-gitlab v1.12.2 (or later) from the Marketplace or the GitHub releases page.
3. Restart / re-enable the plugin.
4. Have an affected user run /gitlab connect with no arguments and confirm they receive the OAuth link.

⚠️ Important: Existing connected users are not affected and do not need to reconnect. No KV-store records need to be created manually after the upgrade; the plugin reads the legacy ClientID/ClientSecret from System Console settings.

Workaround if you cannot upgrade immediately

If the plugin cannot be upgraded right away (for example, while a change-request goes through approval), the bug can be temporarily worked around by re-running the GitLab plugin setup wizard in System Console > Plugins > GitLab and entering any instance name (for example, production) along with the existing OAuth Client ID and Secret. That seeds the keys the v1.12.1 code path expects and unblocks /gitlab connect.