Expose customer generated errors so that they are aware and can resolve

Moved from Azure DevOps (ref: #3076)

This applies to

• Agent Handoff

• Flow

• Flexi-Forms

When a tenant admin enters a URL, there are lots of ways there can be problems and it's up to the tenant admin to solve them.

For example:

• Say they enter the URL http://localhost/MyAwesomeWebService

• This URL won't work.

• The tenant admin needs to know something is wrong, and fix it.

• The sys admins do not need to routinely see this type of issue.

We need to create a new pattern for handling these types of problem.

============

The simple plan, that we have started working on in flow is to:

1. Put a try catch around the HTTP call

2. In the catch block re-throw the exception wrapped in a FlowDeveloperRuntimeException

This way

1. At the system level we can easily filter out these exceptions that we don't want to see

2. At the tenant level we can add a page that shows the tenant admins these exceptions that are a problem and need to be resolved, providing any guidance as necessary.

Sean / Karrim raised the point that Agent Handoff is very activity based and we need to work out how that fits into the general scheme for handling these types of problems.

We need to change the name of the exception a bit to make it more general, maybe TenantConfigurationRuntimeException or something like that. The issue is that the configuration is wrong and it's up to the tenant to fix it and not us.

==================================================

Background information copied Azure DevOps (ref: #2921)

==================================================

Need to define solution

For example:

• Identify the specific problem - subscriber unavailable (how specific can we be; not available, forbidden, page not found, etc.)?

• Make sure people are informed - who and how?

• Confirm what information / error message the end-user sees?

• Do we need the ability to store the data so that it's not lost with a backup method for supplying it to the TenantAdmin?

• How do we store this exception within the logs?

Issues

• In the error log you can't tell this is a form submit failure, without investigating the bug

  • It would be a lot better if the exception was more obvious, say like a "CustomFormSubmitException" - unable to submit form data to the subscriber URL entered

  • It would be really good to have a bit of contextual into in the exception (Tenant, Assistant, Form)

  • We do need to get an exception though, if we were to swallow the exception we would not be able to support the system

• The end user just gets a "something went wrong" message, rather than something more helpful like "I could not submit that form, sorry dude"

  • The tenant admins do not know about the existence of the issue....they get no info

    • We could really do with showing the tenant admin about the error, or proactively contacting them (email / banner in Tenjin Admin?), so they can fix it themselves

  • If they know about the issue, they can fix it themselves by sorting out the submit url, or getting the external system up

Reproduction

1. TenjinDev > Early UAT preview tenant > Your assistant name goes here (TenjinDev-1911)

2. This assistant has a form "My new form name"

3. Raised the form in the bot

4. Entered blank.... form returned with a validation required message

5. Entered james.... after a long wait, bot said something went wrong

6. This created the exception below