retry DAG workflow with depends failed with msg ` Ancestor task node step2 not found` about argo-workflows

[heidongxianhua]

when i rebuild my argo-cli with the #12817, it works well. thank you very much. @agilgur5 @shuangkun @jswxstw

[heidongxianhua]

add some details, when i got this error, i have searched issues and solution in argo docs and github, including the issue #12156 , #11395 and the related prs (#12164 and #12817), i have tested localy, but this does not work. @agilgur5 @shuangkun

[agilgur5]

including the issue #12156 , #11395 and the related prs (#12164 and #12817), i have tested localy, but this does not work

For future reference, if you did that before making this issue, that would have been very helpful context to write in the issue description. Then we'd know this is not necessarily a duplicate without needing to comment 😅

[shuangkun]

I test it in my envirment， I think it has been fixed by #12817 @heidongxianhua can you test again use latest？ I retried it in UI.

[shuangkun]

fixed by #12817

[shuangkun]

May look like this: #12817

[heidongxianhua]

yeah, I have cherry-pick your code, but it still got error. @shuangkun

[agilgur5]

Sounds like a duplicate of #12156?

[shuangkun]

yeah, I have cherry-pick your code, but it still got error. @shuangkun

Strange, I feel like my PR should have fixed this problem. could you submit a pr to fix this?

[heidongxianhua]

sorry, i have no idea to fix it now. and the root cause is the step-3 depends on depends: step1.Succeeded && (step2 || step2.Failed), and the step-2 is failed but step-3 is succeeded at first time. Then when I retry, the wf will delete the failed step-2, so it will make step-3 fail. And further, if I change the dependency depends: step1.Succeeded && (step2 || step2.Failed) to depends: step1.Succeeded, it will retry succeed as expected . So it is may different to the issue in your pr #12817 , but i do not know how to fix it now @shuangkun

[jswxstw]

yeah, I have cherry-pick your code, but it still got error. @shuangkun

Actually, #12817 fixed the argo-cli, not the controller.
Which way are you using to retry the failed workflow? @heidongxianhua
I think you might not be using the argo-cli of the latest version.

[agilgur5]

Actuall, #12817 fixed the argo-cli, not the controller.

It's in the Server -- so any method that retries it (UI, CLI, SDK, direct API) should go through the logic.
(and moving to the Controller per #12538)

[jswxstw]

It's in the Server -- so any method that retries it (UI, CLI, SDK, direct API) should go through the logic.
(and moving to the Controller per #12538)

Yes, I didn't express it clearly. I believe that this issue is most likely caused by using the wrong version of the CLI.

[agilgur5]

Oh did you mean the binaries? Since the Server is part of the CLI, i.e. argo server.

We refer to it as the Server. But yes, @heidongxianhua would have to cherry-pick any fixes into their Server build and update their Server image with the build, not the Controller (which unaffected by those fixes).

[jswxstw]

Oh did you mean the binaries? Since the Server is part of the CLI, i.e. argo server.

😅Yes！In my opinion , CLI == binaries and CLI and argo server should both be updated.

[agilgur5]

😅Yes！In my opinion , CLI == binaries

Generally speaking, the CLI is referred to as a client, as that is it's primary usage. A lot of people don't even know that the CLI embeds the Server (I've also seen people ask what argo server does as they thought it was some client command that connects to the Server or something, not that it literally runs the Server. Also technically the Controller is a separate, single command CLI as well).
In this case, when you referred to the CLI, that sounded like the argo retry command, which is not what you meant. Hence why disambiguation and specificity is important -- let's make sure we specify "the Server" when we refer to it.

[heidongxianhua]

yeah, I will have a test again now.