Twilio Flex Actions errors

[TarikCarvalho08]

Hi,

When testing the actions of holding, releasing and kicking the participant during a call, I get some Flex event errors. The action works after the error is generated but floods the error logs.

If you're in a call with only one participant, the only error that will occur is Action KickParticipant cancelled by before event. To trigger this error, simply try to kick a participant out of a call using the remove participant button. See below for an image of the error:

Now, when a third person is added to the call, every time I put that person on hold, take them off hold or kick them off the call, I get the these errors:

Action HoldParticipant cancelled by before event

Action UnholdParticipant cancelled by before event

Does anyone know how this problem can be fixed? I've had no success on my end.

Thank you for your help!

[dremin]

Hi @TarikCarvalho08! Flex UI always throws these errors whenever an action is aborted. The template is intentionally aborting these in order to override functionality. Are you having an issue with those buttons?

[TarikCarvalho08]

Hi @dremin! But why would they generate errors intentionally, since the buttons were intentionally clicked? I mean, wouldn't they work as intended and not generate any errors that Flex would trigger and log as errors?

I'm not having any problems with the buttons themselves, it's just that every time they're clicked, they generate an error, and since we're using Sentry to report errors occurring in the account, they're catching all of them, so I thought this might be something unintended by Flex's functionality.

I hope that makes sense!

Thanks!

[dremin]

@TarikCarvalho08 We use these actions and abort their default implementations for a few reasons:

• We could replace the action altogether, but this does not scale--when an action is replaced, another feature or plugin could also replace that and completely override the original replacement (only the newest replacement is used).
• We could create our own action instead, but that does not account for the other places throughout Flex UI that may use the out-of-box action. By hooking the out-of-box action, we know that the functionality will be consistent and less likely to break with product updates.

As for why the product emits an error when an action is aborted, that was an intentional design choice that I can only speculate about. However, most logging/monitoring solutions have configurable filtering such that you could exclude these logs from generating alerts, etc, which is what I would recommend for this scenario.

[TarikCarvalho08]

Hi @dremin, thanks for the explanation! I will filter these errors as recommended!

Thank you very much!