What causes "error-unregistering-provider" in RocketChat/Rocket.Chat?

Check the server log for 'Failed to unregister provider' and the underlying err

error-unregistering-provider

Error message

error-unregistering-provider

What it means

AppOutboundCommunicationBridge.unRegisterProvider wraps getOutboundService().outboundMessageProvider.unregisterProvider(appId, provider.type) in try/catch; failures are logged as 'Failed to unregister provider' with the original error and re-thrown as 'error-unregistering-provider'. As with registration, the exception text is generic — the server log carries the root cause.

Solutions

Check the server log for 'Failed to unregister provider' and the underlying err
Only unregister providers you successfully registered (track registration state in the app)
Make register/unregister use the same provider.type value
Treat unregister failure as non-fatal during teardown when the registry is already empty

Defensive patterns

Strategy: try-catch

Validate before calling

const registered = new Set<string>();
const unregisterTracked = async (provider: { type: string }) => {
  if (!registered.has(provider.type)) return; // nothing to unregister
  await app.getRocketChat().getOutboundCommunication().unRegisterProvider(provider);
  registered.delete(provider.type);
};

Try / catch

try {
  await app.getRocketChat().getOutboundCommunication().unRegisterProvider(provider);
} catch (err) {
  if (err instanceof Error && err.message === 'error-unregistering-provider') {
    // non-fatal during teardown; real cause logged server-side
    app.getLogger().warn('provider unregister failed; continuing teardown');
    return;
  }
  throw err;
}

Prevention

Only unregister what you registered — mirror register calls with a state set
Use the identical provider.type value in register and unregister paths
Treat teardown-time unregister failures as warnings, not crashes
Re-check server logs for the underlying 'Failed to unregister provider' entry

When it happens

Trigger: Unregistering a provider that was never registered (e.g. disable handler runs when registration failed earlier); provider.type mismatch between register and unregister calls; the outbound service already torn down (shutdown order).

Common situations: onDisable/onUninstall handlers that assume registration succeeded; apps keeping provider objects that were mutated; server restarts where in-memory registry state was lost but the app still tries to unregister.

Related errors

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

Appendix: source

Thrown at apps/meteor/app/apps/server/bridges/outboundCommunication.ts:42

	}

	protected async registerEmailProvider(provider: IOutboundEmailMessageProvider, appId: string): Promise<void> {
		try {
			this.orch.debugLog(`App ${appId} is registering an email outbound provider.`);
			getOutboundService().outboundMessageProvider.registerEmailProvider(provider);
		} catch (err) {
			this.orch.getRocketChatLogger().error({ appId, err, msg: 'Failed to register email provider' });
			throw new Error('error-registering-provider');
		}
	}

	protected async unRegisterProvider(provider: IOutboundMessageProviders, appId: string): Promise<void> {
		try {
			this.orch.debugLog(`App ${appId} is unregistering an outbound provider.`);
			getOutboundService().outboundMessageProvider.unregisterProvider(appId, provider.type);
		} catch (err) {
			this.orch.getRocketChatLogger().error({ appId, err, msg: 'Failed to unregister provider' });
			throw new Error('error-unregistering-provider');
		}
	}
}

View on GitHub (pinned to b2c16d5842)