argo-workflows: Deleting a workflow on the workflow details page doesn't do anything
Pre-requisites
- I have double-checked my configuration
- I can confirm the issues exists when I tested with
:latest
- I’d like to contribute the fix myself (see contributing guide)
What happened/what you expected to happen?
If you go to the workflows details page and hit delete (and then confirm the delete), you are taken back to the workflows list page… where your workflow is still sat there staring at you 😃
We do not have workflows archiving enabled.
Version
v3.5.0-rc1
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.
any workflow
Logs from the workflow controller
I couldn't find anything useful. I'll update if I find anything.
Logs from in your workflow’s wait container
n/a
About this issue
- Original URL
- State: closed
- Created 10 months ago
- Comments: 28 (28 by maintainers)
Also sent https://github.com/argoproj/argo-workflows/pull/11676. I suspect there are some errors that appear in the UI for a moment before redirecting to the workflow list page.
@shmruin That error occurs when you visit a live workflow details page for a workflow that’s been deleted from the cluster. I am improving the error message in https://github.com/argoproj/argo-workflows/pull/11674.
@tico24 Have you tried @agilgur5’s PR yet?
So I too was unable to reproduce this locally. That being said, as I mentioned on Slack, if my hypothesis is correct, then this is a race condition. Specifically, higher latency (as with a remote server vs. local server) may make this more likely. The low latency of local dev may mean that the request completes shortly before or after the page reload and so is not affected by the connection drop.
I also did try using throttling in browser dev tools, but that did not reproduce either. That being said, I’m not entirely sure how the emulation works under-the-hood and a slow request/response is not entirely the same as network hops to a remote server. Server-side throttling (e.g. a sleep on the request) may be a bit closer to the real thing, but also a bit different. Forgot to try a server-side throttle though.
Wrote up #11711 which hopefully fixes this – if my hypothesis is correct.
Yep exactly what we needed to see. The request went through but was canceled in argo-server.
@agilgur5 Looking forward to your fix 😃
I see what I’d expect to see.
server:
controller still has nothing.
@tico24 They would indicate whether the deletion request has been received and processed. Just do a grep <workflow-name> from the logs.
@tico24 Can you check workflow controller and K8s API server logs? I’d be interested to see if the request has been sent successfully.
@terrytangyuan Sadly, that screenshot is @tico24 's, and I also fail to reproduce this error. I think @agilgur5 's reviews in #11676 makes sense and can be potentially related to this issue, but cannot sure as I cannot make this situation.
The same issue happens with a basic hello world though:
I cannot reproduce this both on master branch and on 3.5.0-rc1 on k3d cluster… 🤔 (I don’t refresh page) Might be moving to workflows list page before workflow is completely deleted? https://github.com/argoproj/argo-workflows/blob/7cb22a2aa33b7f5c92d5d87bfa69faed35b3d06a/ui/src/app/workflows/components/workflow-details/workflow-details.tsx#L203
If you refresh, would it be gone?
cc @toyamagu-2021 This might be related to your fix