jitsi/jitsi-meet · warning
setting password failed
Error message
setting password failed
What it means
The generic branch of _setPasswordFailed: any setPassword failure other than PASSWORD_NOT_SUPPORTED logs 'setting password failed' with the underlying error and shows the generic 'dialog.lockMessage' dialog. Typical underlying errors are AUTHENTICATION_REQUIRED (only moderators can lock), the conference being disconnected, or a server-side XMPP error. The logged 'error' argument is the JitsiConferenceError instance that carries the real cause.
Source
Thrown at react/features/room-lock/middleware.ts:138
* @param {Action} action - The redux action {@code SET_PASSWORD_ERROR} which
* has the error type that should be handled.
* @private
* @returns {*}
*/
function _setPasswordFailed(store: IStore, next: Function, action: AnyAction) {
if (typeof APP !== 'undefined') {
// TODO Remove this logic when displaying of error messages on web is
// handled through react/redux.
const { error } = action;
let descriptionKey;
let titleKey;
if (error === JitsiConferenceErrors.PASSWORD_NOT_SUPPORTED) {
logger.warn('room passwords not supported');
descriptionKey = 'dialog.passwordNotSupported';
titleKey = 'dialog.passwordNotSupportedTitle';
} else {
logger.warn('setting password failed', error);
descriptionKey = 'dialog.lockMessage';
titleKey = 'dialog.lockTitle';
}
APP.store.dispatch(showErrorNotification({
descriptionKey,
titleKey
}));
}
return next(action);
}
View on GitHub (pinned to 98de6219cc)
Solutions
- Ensure the lock request is made by a moderator: check participant.role === 'moderator' (or isModerator(state)) before showing/enabling the password UI; wait for role promotion after joining.
- Verify the conference is in the joined state (conference.getConnectionState() or redux 'joined' status) before locking.
- Retry after reconnection if the failure coincided with a dropped XMPP connection; inspect the full error object logged for the specific JitsiConferenceError reason.
Example fix
// before
conference.lock(newPassword);
// after
const state = store.getState();
if (isModerator(state) && getConferenceState(state).conference) {
conference.lock(newPassword);
} else {
dispatch(showWarningNotification({ titleKey: 'dialog.notModerator' }));
} Defensive patterns
Strategy: try-catch
Validate before calling
const canLock = (state: IReduxState) => isModerator(state) && Boolean(getConference(state));
if (canLock(state)) { dispatch(setPassword(conference, undefined, pwd)); } Type guard
null
Try / catch
conference.lock(pwd).catch((err: JitsiConferenceError) => {
if (err === JitsiConferenceErrors.AUTHENTICATION_REQUIRED) {
showError('You must be a moderator to lock the room');
} else {
showError('Setting password failed, please retry');
}
}); Prevention
- Only allow moderators to open the password dialog.
- Wait for role promotion to moderator before enabling lock controls.
- Avoid lock calls during reconnection; retry once reconnected.
- Inspect the full JitsiConferenceError in logs to distinguish auth vs server errors.
When it happens
Trigger: A non-moderator participant calls conference.lock(password); calling lock after the conference ended or during reconnection; prosody rejecting the IQ with a conflict/forbidden error; attempting to change the password while another lock operation is in flight.
Common situations: Participant role not yet promoted to moderator (moderation delayed after JOIN_RESPONSE), flaky XMPP connection causing lock requests during reconnection, races between two moderators changing the password simultaneously.
Related errors
AI-assisted analysis of jitsi/jitsi-meet@98de6219cc (2026-08-28).
Data as JSON: /api/errors/a89a9ca359e96741.
Report an issue: GitHub.