-
Notifications
You must be signed in to change notification settings - Fork 645
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
Change httpPost to httpGet #8269
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, these are the two that I found as well. Could you deploy this private build to DEV environment and verify the following?
- E2E tests pass
- Gallery functional tests pass
- All scenarios around the changed endpoints still work (manual tests)
@@ -227,9 +227,8 @@ public virtual JsonResult UploadPackageProgress() | |||
return Json(progress, JsonRequestBehavior.AllowGet); | |||
} | |||
|
|||
[HttpPost] | |||
[HttpGet] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why change this one to HttpGet? Doesn't it change DB state and hence should be a POST?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a read-only endpoint. It checks for an already uploaded package (uploads container, not yet submitted) and returns the metadata view model. Otherwise, it returns an empty view model.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The overloads are very confusing here TBH, but if you open it in VS and step through the code, this is the read-only endpoint that is the first step of the UI upload process. A subsequent "verify" endpoint is the POST and does the DB state changes.
If it's related to the failure of functional tests, should we understand what changes make it failed recently but succeed before, rather than suppress it? What if something is happening but functional tests don't have the coverage on it? |
Deployed to dev, E2E tests pass |
No description provided.