Allow skipping when a task is failed

[JCHacking]

I would like the driver to allow when I have a workflow like failed, with a failed task to be able to skip it and continue executing. Either because I can't fix it at that moment or because I have fixed it externally and that task is not restartable

[opoupeney]

You can set the task as optional, Its status will be COMPLETED_WITH_ERRORS but it won't fail the workflow.

{
 "name": "mytask",
 "taskReferenceName": "mytask_8u4c6_ref",
 ...
 "optional": true,
}

[JCHacking]

I am using conductor as an E2E test orchestrator, so it would be good for me if the workflow fails

If in any case I have a task that is a step in a test, it fails, but the teams involved tell me that it is for X thing and that they will fix it, I would like to be able to skip it.

That solution of making the task optional would not work for me, since I understand that if it were like that it would always be skipped and I would not skip it manually when I get a response from the development teams.

From what I see, there is an option to skip a task by making this call:
/api/workflow/{workflowId}/skiptask/{taskReferenceName}
But seeing how it works by analyzing the code, I cannot skip a task that has failed.
As in my case, until a task (Small Test) is executed I cannot know if it fails, that call is not useful for my objective. Could it be feasible to modify the behavior to allow this?

[c4lm]

so it would be good for me if the workflow fails

Then don't make it optional, let workflow fail and retry when that test is fixed.
Task can only be skipped if it has not been processed. If you want to be able to run all tasks in the workflow until that test is fixed, mark it as optional, and once the teams involved say that it has been fixed, update workflow definition and make the task non-optional. You can also use INLINE or SWITCH after the optional task to process its status or create some kind of reporting flow for such optional tests.

[JCHacking]

It doesn't convince me, since I test switch configurations, etc.

So I have a workflow which is switch_test for example, I am not interested in changing the definition of this by generating a new version to be able to continue a specific workflow. It is not something that would apply to all workflows