Skip to contentSkip to navigationSkip to topbar
Page toolsOn this page
Looking for more inspiration?Visit the

Error Handling and Debugging


The Flex UI provides the FlexError class, the FlexError event, and the Error Reporting UI to make it easier to notice and report issues. These tools help you detect, report, and debug errors in your Flex plugins.


The FlexError Class

the-flexerror-class page anchor

The FlexError class is an extension of normal JavaScript Error class, with added context. This class includes more info on errors to help pinpoint problems and consolidate the Flex UI API. For the full reference of the class, visit the Flex UI API documentation(link takes you to an external page).

You'll see FlexErrors in two main contexts:

FlexError in an Action Invocation

flexerror-in-an-action-invocation page anchor

If a Flex Action called by your Plugin fails, it throws a FlexError in its promise rejection. Depending on the error, the FlexError can wrap another error, like an error thrown by the backend.

1
try {
2
await Flex.Actions.invokeAction("SomeAction", payload)
3
} catch(e){
4
// e is FlexError
5
}

Listening to the flexError event

listening-to-the-flexerror-event page anchor

Whenever the Flex UI creates an error in its code, whether it throws it further or not, its creation is reported by flexError event. You can subscribe to that event for your own reporting purposes. The event is strictly informative. The user's actions in the event handler will not have any bearing on how the Flex UI deals with the error itself.

1
manager.events.addListener("flexError", (error) => {
2
// do your own handling/reporting
3
});

Get error reports and logs

get-error-reports-and-logs page anchor
(warning)

Warning

Client-side logs or errors are allowed to contain PII (Personally Identifiable Information) because they are transient and are not saved beyond a user session. By exporting them, however, PII is also exported and saved to the file. Please take proper precautions to protect your customers' data when saving and sharing this file.

Error reports and logs mentioned in the Error UI End User Docs can also be retrieved programmatically. Flex.Monitor.getLogs returns the current logs and Flex.Monitor.getError returns all recorded errors in an array. You can use these methods to implement special reporting or report handling.

1
import { Monitor } from "@twilio/flex-ui";
2
3
Monitor.getErrors(); // returns { errors: [Monitor.FlexErrorJSON] }
4
Monitor.getLogs(); // returns { logs: 'string' }
5

For the full reference of the Monitor API, see the Flex UI API documentation(link takes you to an external page).

Flex UI Degraded mode and Client Manager

flex-ui-degraded-mode-and-client-manager page anchor

As of Flex UI v1.31, Flex UI can initialize and function in Degraded mode. You can find the list of components that Flex UI relies on and can start up in degraded mode in the ClientManagerHelpers API reference(link takes you to an external page).

Flex UI exposes ClientManager APIs that you can use to simulate one or more SDKs running in a degraded state. Use these APIs to test the behavior of Flex UI and Flex plugins and make sure your custom logic handles specific degraded Client scenarios.

To test specific Client degradations, use the forceDegraded method to degrade the required Client or Clients. Since the Client Manager degrades a client during its initialization, you can only use the forceDegraded method before the start of the Flex manager initialization.

To reset the force-degraded clients, remove the forceDegraded method call and reload the page. For a more detailed description of these APIs, see the Flex UI API Reference for ClientManager(link takes you to an external page).


  • Experiment with the Actions Framework to practice error handling
  • Develop a new Flex Plugin and listen for the flexError event
  • Set up an integration with the Twilio Debugger