[FEATURE] Communicate to users when detector is initializing

[kamingleung]

Is your feature request related to a problem?
When a detector is being created, it may take up to 20+ seconds to complete the creation. Users currently have to wait in the Create flow to complete in order to proceed.

What solution would you like?
When a user submits the detector creation, we should redirect the user back to the detector details page. In the details page, we should communicate to users that the detector is being initializing in the status as well as a banner to inform users.
Anomaly detection has a similar experience today when users create anomaly detectors:

What alternatives have you considered?
Open to ideas, feel free to comment here!

Do you have any mockups?
To be added.

[paladin-tech]

@kamingleung I can see at least one major UX issue here. Since Detector is being created in the background as an asynchronous process, currently a user has to wait for that process to be over before being brought back to Detector details page.
Your solution would not have issues if we knew that process will be a success (which we don't by default), so if anything goes wrong we are losing a moment to bring up a UX warning that the Detector creation failed.
If we still want to let a user go to details page before the creation flow is over, we need to add some UI elements to notify a user that the creation failed, as well as controls to have him back to create flow, so that error can be fixed.

[kamingleung]

@paladin-tech @sbcd90

1. I am wondering what tasks are taking up the extra time for the detector creation to complete? Can we shorten the creation time?
2. What are the common creation failures?
3. Are the failures fixable by configuring the detector? If so, can we have inline validations, so users can make corrections before they even click "Create".

[jovancacvetkovic]

@kamingleung let me check what delays we have now when a user creates the detectors and I will write these here so that we can figure out the best way to communicate with users.

[jovancacvetkovic]

@kamingleung Current state:

• for me creation is instant, with no delays, what can cause the delay: network or server is too busy
• fields that are not mandatory and the user can continue without those: Run every (can be empty), Rule names (can be empty), Rule severity (can be empty)
  Throws an error

Failed to create detector:

[json_parse_exception] Current token (VALUE_NULL) not numeric, can not use numeric value accessors at [Source: (org.opensearch.common.io.stream.InputStreamStreamInput); line: 1, column: 132]

We should consider adding some UI validation.

[kamingleung]

@jovancacvetkovic Rule names and Rule severities can be empty as discussed here.
Let's check if Run every is required by the API. I would recommend creating a new issue on this validation discussion. Thanks.

[jovancacvetkovic]

Created ticket per comment #378

[jovancacvetkovic]

@kamingleung I'll start working on this soon, can you drop the banner text here or any mocks that would be useful?

[jovancacvetkovic]

@kamingleung, @amsiglan I have a few questions/suggestions:

1. Is this banner text ok while in the process: Attempting to create the detector.?
2. View detector configuration button should be visible only if the request fails?
3. While in the process the status should be: Detector name • Initializing?
4. If there is an error, the status should be: Detector name • Failed and the button View detector configuration should be visible?

[jovancacvetkovic]

@kamingleung @amsiglan Hey, check the new screenshots.

[kamingleung]

Hi @jovancacvetkovic

A few follow-up questions:

1. What are the different errors that will cause the detector creation to fail? Can you list them out?
2. What happens when a detector is in the failed state? Does the detector remained in the list of detectors with a failed status?
3. Can users delete the failed detector?
4. Can users update configuration of a failed detector to make it active?

[jovancacvetkovic]

@kamingleung
1. All errors that can come or be validated on UI are controlled on the Create detector page (eg validating mandatory fields), there are errors that can't be controlled/validated on UI and are triggered by the backend - they should be checked with backend devs.
2. 4. When the detector creation fails, the detector configuration is saved on UI only and the user can try and fix the configuration and try to create the detector again.
3. Failed detectors are not saved, and if a user leaves the page all progress is lost.