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

  1. 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.
  2. Verify the conference is in the joined state (conference.getConnectionState() or redux 'joined' status) before locking.
  3. 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

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.