Connectors Failure message

Author: Yubo Xing | Last edit: May 24, 2023 | Design type: Alerting | Product area: Kafka

Overview

Failed status and failure message

When an error occurs or configuration is wrong, the connector instance will get into failed status, so as an admin or user, they want to inspect why the connector instance failed and how to troubleshoot it, so they would ensure that instances are always available. 

Failed status displays in the table column to indicate the current status of the resource is. The failed status displays with an exclamation icon in front of the clickable text label indicating that the user can click the text “failed” to get more explanation

Failure messages — tableview(Archived)

The users can click the status text “failed” to see a popover that provides more information about why it happens and help the user can look for.  

This design is the first implemented when the service is available as a preview, at this time, we can not provide as much detailed information as possible. Once the API could provide more specific information, we can transition the “failed” status and popover pattern to failure messages.

Failure messages — drawer

The user can click the instance row or “Details” action in the kebab menu to see a drawer that provides more information about what failure happens and how to resolve it.

Inline Alerts were used in the drawer to notify users in a context that something is wrong and needed their attention. Click the angle to expand the inline alert will display more detailed information about the alert.

PF component:Expandable alert

Inline alert is concise when it is folded.

Inline alerts display more info when it is expandable.

Open question: This behavior isn't actually supported with the current clipboard copy component. What would be recommended for this situation?

Failure messages — overview page

The user can click the instance name to open the overview page to see details deeper. 

Inline alert is concise when it is folded.

Inline alerts display more info when it is expandable.

Three cases for alert content

Alert could provide multiple ways to help users to look for help.It depends on who the user is. Typically, we divide users into two groups: 

• Eval users: who do not have a subscription so they can not qualify for support.
• Non-eval users： who have a subscription and qualify for support

During the initial product phases, it is unknown whether the service can support user subscriptions and whether it can distinguish between eval users and non-eval users.

So in order to provide general information to different users and phases, there are three user cases based on the subscription:

Case 1: Error alert - initial implement (works for when the user qualifies for support AND for when a user does not qualify for support)

Case 2: Error alert - future implement -Not eval (user has a subscription and qualifies for support）The link is the external link icon to the help site.

Case 3 : Error alert -future implement- Eval (user does not have a subscription and does not qualify for support) The link in this text is a mail to the link which opens the user’s email client.

Content