-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
fix #540 #246
fix #540 #246
Conversation
/ok-to-test |
All the checks pass in our CI - Are you still experiencing issues building locally @Horiodino fyi @michael-valdron |
is the code working as expected ? |
yep i can build image and test case is running! |
No issues locally anymore? @Horiodino |
nope |
@@ -543,6 +543,12 @@ func buildIndexAPIResponse(c *gin.Context, indexType string, wantV1Index bool, p | |||
if params.Deprecated != nil { | |||
util.FilterDevfileDeprecated(&index, *params.Deprecated, wantV1Index) | |||
} | |||
if index == nil || len(index) == 0 { | |||
c.JSON(http.StatusOK, gin.H{ |
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.
c.JSON(http.StatusOK, gin.H{ | |
c.JSON(http.StatusInternalServerError, gin.H{ |
I'm wondering if this should be a 500 instead of a 200 as it not having the samples is technically an error and is referenced as an error in the original issue
https://go.dev/src/net/http/status.go
wdyt @michael-valdron
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.
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.
I was thinking 500
as it would be the servers fault no samples were loaded, no? I am also okay with 404
though
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.
I was thinking
500
as it would be the servers fault no samples were loaded, no? I am also okay with404
though
That is a good point, but in this case the control logic that provides this response does not guarantee that the stacks and samples are not loaded due to error versus just having an empty registry.
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.
I'm okay with 404
in that case.
@Horiodino for reference that is http.StatusNotFound
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.
IMO, in a world where we're working towards more dynamic devfile registries, I'd argue that a 200 code is fine here.
index/server/pkg/server/endpoint.go
Outdated
@@ -543,6 +543,12 @@ func buildIndexAPIResponse(c *gin.Context, indexType string, wantV1Index bool, p | |||
if params.Deprecated != nil { | |||
util.FilterDevfileDeprecated(&index, *params.Deprecated, wantV1Index) | |||
} | |||
if index == nil || len(index) == 0 { | |||
c.JSON(http.StatusOK, gin.H{ | |||
"status": "No samples found in the registry", |
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.
Because this response is returned if index has no entries and not just the samples, the status should mention stacks too:
"status": "No samples found in the registry", | |
"status": "No stacks or samples found in the registry", |
Signed-off-by: Horiodino <holiodin@gmail.com>
index/server/pkg/server/endpoint.go
Outdated
@@ -543,6 +543,12 @@ func buildIndexAPIResponse(c *gin.Context, indexType string, wantV1Index bool, p | |||
if params.Deprecated != nil { | |||
util.FilterDevfileDeprecated(&index, *params.Deprecated, wantV1Index) | |||
} | |||
if index == nil || len(index) == 0 { | |||
c.JSON(http.StatusNotFound, gin.H{ |
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.
TBH, I think this should actually be http.StatusOK
.
@michael-valdron @Jdubrick It might be unusual to have a registry return no stacks, but IMO, I think 200 is more appropriate here than 404 or 500, especially as we work towards a more dynamic registry in devfile/api#1505
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.
I'm okay with reverting it back to a 200
response. @Horiodino feel free to revert that change
Signed-off-by: Horiodino <holiodin@gmail.com>
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.
Tested locally - Removed extraDevfileEntries.yaml
from the tests
directory and created the registry. After hitting /index/sample
I was able to receive the correct response.
@michael-valdron since you requested changes I'll wait until you take a look as well before merging
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.
/lgtm
Tried locally with an empty index, works as expected in headless:
@devfile/devfile-services-team I noticed that when the index empty that the registry viewer is throwing errors:
TypeError: devfileJsons[devfileRegistryIndex].map is not a function
at /app/apps/registry-viewer/dist/.next/server/chunks/951.js:5066:110
at Array.flatMap (<anonymous>)
at fetchDevfiles (/app/apps/registry-viewer/dist/.next/server/chunks/951.js:5066:33)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async getServerSideProps (/app/apps/registry-viewer/dist/.next/server/pages/index.js:205:25)
at async Object.renderToHTML (/app/node_modules/next/dist/server/render.js:507:20)
at async doRender (/app/node_modules/next/dist/server/base-server.js:720:34)
at async cacheEntry.responseCache.get.incrementalCache.incrementalCache (/app/node_modules/next/dist/server/base-server.js:837:28)
at async /app/node_modules/next/dist/server/response-cache/index.js:83:36
If we are expecting a devfile registry to have a case with an empty index, there should be a follow issue created to address this on the registry viewer.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Horiodino, Jdubrick, michael-valdron The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@Horiodino Changes looks good and merging this now, thanks for your contribution towards this! |
🙌 Looking forward to working more , thanks |
Please specify the area for this PR
What does does this PR do / why we need it:
Which issue(s) this PR fixes:
Fixes #devfile/api#540
PR acceptance criteria:
Documentation (WIP)
How to test changes / Special notes to the reviewer: