What

Accessing errors when an instance is in a Failed state

When a user configures an instance, it’s possible that the instance enters a failed state due to bad configuration data. In this case, the user should be able to see that the instance is failed with an additional explanation about the reason why it’s failed.

Accessing errors related to error handling

Error handling options allow a user to decide what happens when there’s a message failure in a running instance.

• When a user configures error handling on a Connectors instance, they need additional information about what the error handling options are.
• After error handling is defined, they need to be able to see details about the number of message failures that exist as well as information about where to find more information that explains why the message failure happened.

The following are the error handling options, and variations in how they affect the user experience through the create, edit, and troubleshooting flows.

• Stop - When a message failure occurs, the Connectors instance status will change from Running to Stopped.
  • An instance that is stopped due to the error handling config should include additional details in the table view to inform the user that the instance is stopped due to an error.
  • The user should be able to access more details about the message failure.

• Ignore - When a message failure occurs, the Connectors instance status does not change and it remains in a Running status.
  • This option is currently labeled “Logs” but should be relabeled to “Ignore”
  • If the selected namespace option is in a customer-owned OSD, then the user should see additional information about error messages being available in the logs on the openshift cluster. Some variation of this information should be provided during create, edit and view.
    • This information should communicate to the current user that they can reach out to the cluster admin to access the logs
    • Ideally, we should provide a link to the logs as part of this information.

• Dead letter queue - When a message failure occurs, the Connectors status does not change and it remains in a Running status.
  • The user can access see the messages that have failures in the topic specified as part of this error handling method. These failed messages will include the error reason in the message header.
  • The user should see additional information about error messages being available as part of the message header. Some variation of this information should display during create, edit and view.
  • Ideally, the user would have a link to the Messages tab of the Kafka topic that they specified.
    • A UI preview showing the Messages tab contents is available here. In this UI, the user can click a row, then select the Headers tab in the drawer to see the contents of the message header which will include the message failure reason.

Knowing when an instance has errors

For each instance, we will have error/success statistics that provide a count of how many messages were successful and how many had errors. These details should be available to the user.

Refer to the job stories in the epic brief for more details that are not captured here.

How

• Provide designs that illustrate how to address all UX-focused job stories listed in the epic brief 
• When providing new designs, include examples of the current UI when possible so that reviewers can see the current implementation versus what is being recommended (e.g. how does status currently display, how are errors currently displayed).
• Refer to existing design patterns for showing status.
  • In the table view, there might be some patterns available here that can be reused.
  • In the drawer, there might be some patterns available here that can be reused.

Done

• Ideas are shared in the Design Feedback chat space for review with UXD team members.
• Ideas are shared with the team for review
• Following feedback, a final proposal is created and shared for a follow-up review with both UXD and the product team.