[Feature][Master] Display the workflowInstance/taskInstance failed reason

[ruanwenjun]

Search before asking

• I had searched in the issues and found no similar feature requirement.

Description

If a workflow instance/ task instance is failed, we need to query the log and find out why it failed.

Can we save the failed reason to db as metadata, and display on the ui?

Use case

No response

Related issues

No response

Are you willing to submit a PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[github-actions]

Thank you for your feedback, we have received your issue, Please wait patiently for a reply.

• In order for us to understand your request as soon as possible, please provide detailed information、version or pictures.
• If you haven't received a reply for a long time, you can join our slack and send your question to channel #troubleshooting

[fuchanghai]

I may not feel good if it just saves the error message. Because many times the error message has to be seen against the context of the program. If the context is also stored together, the larger context will cause oom，personal opinion only

[ruanwenjun]

I may not feel good if it just saves the error message. Because many times the error message has to be seen against the context of the program. If the context is also stored together, the larger context will cause oom，personal opinion only

The error message is not exception stack, it is defined in master/worker, e.g dispatch failed, server error, workflow definition doesn't exist ...

[fuchanghai]

@ruanwenjun Can I understand it this way, our previous logs are just the output produced by the task execution. But before execution, he may also report an error, but the user cannot view it on the front end, and can only find this error in the log file afterwards. so we should do this

[ruanwenjun]

@ruanwenjun Can I understand it this way, our previous logs are just the output produced by the task execution. But before execution, he may also report an error, but the user cannot view it on the front end, and can only find this error in the log file afterwards. so we should do this

Yes, and the workflow may execute failed due to some other reason, we didn't display workflow log on the ui.

[fuchanghai]

@ruanwenjun Can I understand it this way, our previous logs are just the output produced by the task execution. But before execution, he may also report an error, but the user cannot view it on the front end, and can only find this error in the log file afterwards. so we should do this

Yes, and the workflow may execute failed due to some other reason, we didn't display workflow log on the ui.

I suggest not just logging error messages, we should log the execution flow。eg:(start_process(success)->buildDAG (success)-> put into task queue (success)->handleCommon(failed)). this allows users to more clearly understand what went wrong in the execution.

[ruanwenjun]

@ruanwenjun Can I understand it this way, our previous logs are just the output produced by the task execution. But before execution, he may also report an error, but the user cannot view it on the front end, and can only find this error in the log file afterwards. so we should do this

Yes, and the workflow may execute failed due to some other reason, we didn't display workflow log on the ui.

I suggest not just logging error messages, we should log the execution flow。eg:(start_process(success)->buildDAG (success)-> put into task queue (success)->handleCommon(failed)). this allows users to more clearly understand what went wrong in the execution.

The error message will be user friendly.

[caishunfeng]

Good idea.
I found that ds workflow instance loss some message, such as stop reason, maybe it's stopped by workflow execute strategy or others, but we have to spend time searching and locating the cause from logs.
So we need this failed reason to help users locate problems.

[caishunfeng]

Here is my design of state history:

• Add a new column of status description to the workflow instance list, the format is as follows:

RUNNING → READY_PAUSE → PAUSE → RUNNING → STOP

• Hover or click to display the specific historical status description, as follows:

[fuchanghai]

Here is my design of state history:

• Add a new column of status description to the workflow instance list, the format is as follows:

RUNNING → READY_PAUSE → PAUSE → RUNNING → STOP

• Hover or click to display the specific historical status description, as follows:

Can you list all the states you can think of，This might give me an idea of ​​where you'd add the logic to add these states