-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v3.5.7+ changes some http response status codes from GET Workflow #13558
Comments
Could you give some example API requests to make this easier to reproduce and debug? As far as I know, the API logic is mostly unchanged in 3.5 other than the Unified Workflows List (i.e. #11121) |
Sure @agilgur5:
It also change the response of the following endpoints:
|
Some more follow-up questions:
|
NO
YES
Not sure, I could't see, I need to rollback the upgrade as fast as possible 😞.
The Authorization header with the Bearer token. The most important info I can give you is that without changing nothing on my side a lot of tests, which validates the ArgoWorkflow API responses, start to fail. Rolling back to the v3.4 version everything back to work again. |
Ok, so it's giving a 404 instead of a 401 even when the Workflow exists 🤔
I imagine you were able to test locally or on a staging/dev env if you tried
There's two of those;
Yea I got that, and I did mark this as a regression according to that, I'm just not recalling any intentional change to API responses, so it's likely an unintentional bug somewhere, which is a lot harder to track down 🫠 More information helps with a repro to try to debug that |
My best guess would be this is an unintentional side effect of #13021. |
Yes.
Yes, sure. I'll update again run the tests and give you more info.
In my case I'm using the
Yes, I was taking a look to the latest releases notes and I didn't see too any change related 😔. |
No. The CLI doesn't affect responses from the API, it's just a client. |
Ok after digging through the I'll follow-up more tomorrow and this week, there might be some other bugs related to that as well. |
Correction, #11674 was correct, but #13021 / #12736 indeed made some alterations to the same exact place apparently, these lines specifically. This does mean it affects v3.5.7+ specifically I should have a fix out soon |
Pre-requisites
:latest
image tag (i.e.quay.io/argoproj/workflow-controller:latest
) and can confirm the issue still exists on:latest
. If not, I have explained why, in detail, in my description below.What happened? What did you expect to happen?
In the latest images some endpoints change their status responses.
When I call this endpoints:
I start returning a 404 when in previous version (3.4.x) the status code was a 401.
Version(s)
v3.5.7+
Paste a minimal workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflows that uses private images.
It's an http call, not related with the workflow itself.
Logs from the workflow controller
Logs from in your workflow's wait container
The text was updated successfully, but these errors were encountered: