RocketChat/Rocket.Chat · info

The default value of the custom setting has changed. Please

Error message

The default value of the custom setting has changed. Please review your settings.

What it means

Second phase of migration 317, covering CUSTOM OAuth providers. It queries all Settings whose _id matches /^Accounts_OAuth_Custom-[a-zA-Z0-9_-]+-button_color$/ — one document per custom OAuth provider's button background color. For each, if value === packageValue (meaning the admin never customized it; the stored value is still the shipped package default #1d74f5), it warns with the setting _id and updates the value to the new default background #e4e7ea. Providers with a customized color (value !== packageValue) are skipped.

Source

Thrown at apps/meteor/server/startup/migrations/v317.ts:94

			})
			.filter(isTruthy);

		await Promise.all(promises);

		const customOAuthButtonColors = await Settings.find({
			_id: { $regex: /^Accounts_OAuth_Custom-[a-zA-Z0-9_-]+-button_color$/ },
		}).toArray();
		const customOAuthButtonLabelColors = await Settings.find({
			_id: { $regex: /^Accounts_OAuth_Custom-[a-zA-Z0-9_-]+-button_label_color$/ },
		}).toArray();

		const buttonColorPromises = customOAuthButtonColors
			.map(({ _id, value, packageValue }) => {
				if (packageValue !== value) {
					return;
				}

				SystemLogger.warn({
					msg: 'The default value of the custom setting has changed. Please review your settings.',
					_id,
					newValue: newDefaultButtonColor,
				});

				return Settings.updateOne({ _id }, { $set: { value: newDefaultButtonColor } });
			})
			.filter(isTruthy);

		const buttonLabelColorPromises = customOAuthButtonLabelColors
			.map(({ _id, value, packageValue }) => {
				if (packageValue !== value) {
					return;
				}

				SystemLogger.warn({
					msg: 'The default value of the custom setting has changed. Please review your settings.',
					_id,

View on GitHub (pinned to b2c16d5842)

Solutions

  1. If the neutral gray default is fine, no action is needed.
  2. To re-brand a specific provider, edit its button_color in Admin -> OAuth -> <custom provider> (or set Accounts_OAuth_Custom-<Name>-button_color) to your brand color, e.g. #1d74f5.
  3. To protect colors before upgrading, change the value away from the package default — the migration's value === packageValue check then skips that provider.
  4. After adjusting, restart or re-run service configuration update so the login buttons render the new colors.

Example fix

// re-brand a custom OAuth provider post-migration
await Settings.updateOne(
  { _id: 'Accounts_OAuth_Custom-mySso-button_color' },
  { $set: { value: '#1d74f5' } },
);
Defensive patterns

Strategy: validation

Validate before calling

// Pre-upgrade: list custom OAuth providers whose button_color will be recolored
const atRisk = (await Settings.find({
  _id: { $regex: /^Accounts_OAuth_Custom-[a-zA-Z0-9_-]+-button_color$/ },
}).toArray()).filter(({ value, packageValue }) => value === packageValue);
console.log(atRisk.map(({ _id }) => _id)); // these get #e4e7ea from migration 317

Prevention

When it happens

Trigger: Migration 317 runs after upgrade, and at least one custom OAuth provider (created via Admin -> OAuth -> Add custom OAuth) still has its button_color equal to the package default — i.e. the admin never changed the color. Each such provider logs one warning and gets its button background recolored to #e4e7ea.

Common situations: Workspaces with custom OAuth providers (internal SSO with bespoke names) upgrading across the redesign release. Because custom providers are often created and forgotten, most will match packageValue and silently turn gray, prompting admins to wonder why their login buttons changed branding.

Related errors


AI-assisted analysis of RocketChat/Rocket.Chat@b2c16d5842 (2026-08-18). Data as JSON: /api/errors/91f891f11c64fc8b. Report an issue: GitHub.