RocketChat/Rocket.Chat · error
Type not supported
Error message
Type not supported
What it means
Thrown by POST /api/apps/ui.interaction/:id when the request body's type field matches none of the three supported core-app interaction types: 'blockAction', 'viewSubmit', 'viewClosed'. The switch's default branch rejects anything else with HTTP 500 { error: 'Type not supported' }. The endpoint only reaches the switch for apps registered as UiKitCoreApp; other app ids fall through to next().
Solutions
- Send one of the supported values for type: 'blockAction', 'viewSubmit', or 'viewClosed' with the matching payload shape for each case.
- Check for typos (e.g. 'blockActions') and that the field is at the body top level.
- If you need a newer interaction type, upgrade the Rocket.Chat server to a build whose uikit router supports it.
- Confirm the appId in the URL is actually a UiKitCoreApp-registered core app; non-core apps bypass this handler entirely.
Example fix
// before
await fetch(`/api/apps/ui.interaction/${appId}`, {
method: 'POST',
headers,
body: JSON.stringify({ type: 'blockActions', actionId, payload }), // typo -> 500
});
// after
await fetch(`/api/apps/ui.interaction/${appId}`, {
method: 'POST',
headers,
body: JSON.stringify({ type: 'blockAction', actionId, triggerId, payload, container }),
}); Defensive patterns
Strategy: type-guard
Validate before calling
const SUPPORTED = new Set(['blockAction', 'viewSubmit', 'viewClosed']);
if (!SUPPORTED.has(payload.type)) throw new RangeError(`type must be one of ${[...SUPPORTED].join(', ')}`); Type guard
type SupportedInteraction = 'blockAction' | 'viewSubmit' | 'viewClosed';
function isSupportedInteraction(t: unknown): t is SupportedInteraction {
return t === 'blockAction' || t === 'viewSubmit' || t === 'viewClosed';
} Try / catch
try {
const res = await fetch(`/api/apps/ui.interaction/${appId}`, { method: 'POST', body: JSON.stringify(payload) });
if (res.status === 500) {
const { error } = await res.json();
if (error === 'Type not supported') fixPayloadType(payload);
}
} catch { /* network errors only; HTTP 500 handled above */ } Prevention
- Type the interaction payload in the client with a literal union so invalid types fail at compile time.
- Keep client SDK and server versions aligned when new interaction types appear.
- Send the payload through a small serializer per interaction type instead of hand-building bodies.
When it happens
Trigger: Posting a body with type: 'kanbanAction' or any newer/legacy interaction type to a core-app id; a typo like 'blockActions' or 'viewSubmited'; a client library from a different Rocket.Chat version emitting an interaction type this server build does not handle yet.
Common situations: Client/server version skew after upgrading one side (new interaction types added in newer builds); hand-rolled integrations guessing the payload schema; copy-paste from apps-engine examples that use non-core types handled elsewhere.
Related errors
- Invalid app provided
- error-id-param-not-provided
- error-invalid-arguments
- error-invalid-challenge-method
- error-invalid-event-type
AI-assisted analysis of RocketChat/Rocket.Chat@b2c16d5842 (2026-08-18).
Data as JSON: /api/errors/0828a68ffef77aae.
Report an issue: GitHub.
Appendix: source
Thrown at apps/meteor/ee/server/apps/communication/uikit.ts:192
const result = await UiKitCoreApp.viewClosed({
appId,
triggerId,
type,
user,
payload: {
view,
isCleared,
},
});
// Using ?? to always send something in the response, even if the app had no result.
res.send(result ?? {});
return;
}
default:
throw new Error('Type not supported');
}
} catch (e) {
const error = e instanceof Error ? e.message : e;
res.status(500).send({ error });
}
});
export class AppUIKitInteractionApi {
orch: IAppServerOrchestrator;
constructor(orch: IAppServerOrchestrator) {
this.orch = orch;
router.post('/:id', this.routeHandler.bind(this));
}
private async routeHandler(
req: UiKitUserInteractionRequest,View on GitHub (pinned to b2c16d5842)