appError

Emitted when something unexpected or not allowed happens in the room.

Here is a list of the possible error names:

• permissions-rejected -> emitted when user tries to screen share, but browser doesn't have enough permissions for it

• not-allowed -> emitted when a not allowed action was requested by the user. For example if a user tries to start a recording and recording is not supported in the room, you will receive a not-allowed type.

• forbidden-action -> emitted when a forbidden action was requested by the user. For example if a user tries to end a session and doesn't have a permission to do so, then the forbidden-action type.

• authorization-failed -> emitted when a user's authorization into the room is rejected — for example a display name that fails room validation.

• command-failed -> emitted when an SDK method call fails to be processed on the room side. The data.command field tells you which method failed. If data.command is "connect", treat this as fatal: the room did not finish loading and will not recover on its own — reload the iframe or show your own error state rather than treating it as a single failed call.

Sample payload

{
  "type": "appError",
  "data": {
      "name": "not-allowed",
      "message": "Recording disabled. You’ll need to edit this room’s properties to record sessions in this room",
      "data": {
         "type": "recording"
      }
  }
}

Starting from v0.0.58 of @digitalsamba/embedded-sdk, not-allowed can also occur when you call a session-only command (recording, screenshare, whiteboard actions, remote-user actions, hand raise/lower, and similar) before you've joined the session, or after you've left or the session has ended. In that case data.type is "not-joined" and data also includes the command name:

{
  "type": "appError",
  "data": {
    "name": "not-allowed",
    "message": "Command \"removeUser\" requires an active session",
    "data": {
      "type": "not-joined",
      "command": "removeUser"
    }
  }
}

If your integration inspects data on not-allowed errors, make sure it tolerates data.type values it doesn't recognize yet and the additional data.command field — don't assume data only ever has a type key.

{
  "type": "appError",
  "data": {
      "name": "forbidden-action",
      "message": "Forbidden action. This participant is not allowed to end session",
      "data": {
         "type": "end-session"
      }
  }
}

{
  "type": "appError",
  "data": {
    "name": "authorization-failed",
    "message": "User authorization failed",
    "data": {
      "message": "<underlying error message>"
    }
  }
}

{
  "type": "appError",
  "data": {
    "name": "command-failed",
    "message": "Failed to process SDK command \"startRecording\"",
    "data": {
      "command": "startRecording"
    }
  }
}

message on command-failed always follows the template Failed to process SDK command "<command>", where <command> is the exact method/command name you called.

Sample subscription code

sambaFrame.on('appError', (error) => {
  console.log(error);

  /* outputs  
    {
      name: 'not-allowed',
      message:
        'Recording disabled. You’ll need to edit this room’s properties to record sessions in this room',
      'data': {
         'type': 'recording'
      }
    }
  */
});