Open vermaxik opened 1 year ago
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
I can't seem to reproduce this. Here's what I did:
argo submit
, which is almost the same as the one in the issue description, except it calls https://httpbin.org/uuid so we can easily identify changes by looking for the returned UUID:
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: http-template-
spec:
entrypoint: main
onExit: exit-handler
templates:
- name: main
http:
method: POST
url: https://www.google.com/foo/bar
- name: exit-handler
http:
method: GET
url: https://httpbin.org/uuid
argo get http-template-sx7w5 -o yaml | grep uuid
to get the UUID generated by the exit handler, which returned "uuid": "9472c8a9-b36d-4da8-a7d1-4a0491ed6394"
argo retry http-template-sx7w5
"uuid": "ec3cb475-b7eb-4e46-ae2c-1728ffcb357b"
. That proves the exit handler was called a second time.
Pre-requisites
:latest
What happened/what you expected to happen?
We've switched from
container
templates tohttp
template and got unexpected behaviour on retry (both in a pod and a archived).There are 2 API for the retry: -
argo retry workflow-name
-argo archive retry workflow-name
We use both: first when the pod still in k8s, and second when the pod GC (archived).Actual behaviour:
argo retry workflow-name
on exit handler is ignoredargo archive retry workflow-name
on exit handler is stuck infinity in running stateExpected behaviour:
argo retry workflow-name
on exit handle should run anyway as it's in a container templateargo archive retry workflow-name
on exit handler should not stuck and run anyway as it's in a container templateVersion
3.4.7 (latest)
Paste a small workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflows that uses private images.
Logs from the workflow controller
Logs from in your workflow's wait container