Store error reasons for mission, task and step

[aeshub]

Describe the new feature you would like to see After the implementation of https://github.com/equinor/isar/pull/457 ISAR will now include an error description with the MQTT messages that are sent when the status for a mission, task or step is updated. The MQTT message contains two fields

1. ErrorDescription (This contains a log message with some detailed information about what went wrong)
2. ErrorReason (This points to the type of exception which was raised in ISAR to cause this error)

Flotilla should

• Store the ErrorDescription and ErrorReason as fields on the respective models for mission, task and step when an MQTT message is collected (see here https://github.com/equinor/flotilla/blob/main/backend/api/EventHandlers/MqttEventHandler.cs#L350-L386 for how we currently update the status of a task)
• Show the user a valuable error message based on the ErrorReason

It might be that the ErrorDescription should just be stored on the mission while the ErrorReason is used as an error code which translates into a default message for that type of error. For example

• The ErrorReason is "robot_communication_exception"
• The ErrorDescription is "Failed to schedule step {id} because: Unable to communicate with robot"
• The user facing description for ErrorReason "robot_communication_exception" could be " The step failed as the system was not able to communicate with the robot"

Note that the frontend part of this issue is covered by #757

Describe the solution you'd like The end result of this issue should be that the information from ISAR messages are stored on the mission, task and step models such that #757 may implement the user facing error feedback.

How will this feature affect the current Threat Model?

• Should constitute a great improvement in error feedback to users which again will enable us to quicker identify issues which might also affect the threat model.

[andchiind]

Storing this internal information on the database objects might mean that we need to create a new DTO for the mission controller endpoint, so that these errors are not exposed when retrieving missions with GET requests. We are currently returning the Mission data without any editing. Unless we want to assume that this is open information to anyone who can call the endpoints.

[aeshub]

This issue has automatically been marked as stale as there has been no activity for 60 days.

[oysand]

Issue completed

[andchiind]

It doesn't seem as if this issue has been completed, as the errors are not being received in Flotilla from Isar, so I'm reopening this

[aeshub]

This issue has automatically been marked as stale as there has been no activity for 60 days.

[aeshub]

This issue has automatically been marked as stale as there has been no activity for 60 days.

[aeshub]

This issue has automatically been marked as stale as there has been no activity for 60 days.