Skip to content
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

gofiber upgrade to v2.51.0 and application/problem+json update #226

Merged
merged 7 commits into from
Mar 2, 2024
Merged

gofiber upgrade to v2.51.0 and application/problem+json update #226

merged 7 commits into from
Mar 2, 2024

Conversation

richardrdev
Copy link
Contributor

@richardrdev richardrdev commented Feb 23, 2024

Not actually ready to merge yet, due to failing tests (see below)

I believe this is right, but I wanted to check that this is looking right to y'all.

Response looks good, identical to response before change, except that the order of properties is moved around.

Because of the changed order in the response, many tests will need to be changed. For example in TestApi:

expectedBody: `{"title":"Not Found","detail":"Cannot GET /v1/i-dont-exist","status":404}`,

will need to become

expectedBody: `{"detail":"Cannot GET /v1/i-dont-exist","status":404,"title":"Not Found"}`,

and so on. Lots of little manual changes in the expected body values. I'll also need to add a check for empty details, because some tests are failing due to details: "" being included in the response.

I can do those manual changes in the tests, but it'll take some time so I'll need to come back to it later today or tomorrow.

Also, I went ahead and upgraded gofiber to v2.51. Doesn't seem to introduce any breaking changes, so I assume that's fine? I didn't check the gofiber upgrade very thoroughly; I would understand if that needs to be a separate PR though.

@bfabio
Copy link
Member

bfabio commented Feb 24, 2024

Not actually ready to merge yet, due to failing tests (see below)

I believe this is right, but I wanted to check that this is looking right to y'all.

Looks perfect, thanks!

Response looks good, identical to response before change, except that the order of properties is moved around.

Because of the changed order in the response, many tests will need to be changed. For example in TestApi:

expectedBody: `{"title":"Not Found","detail":"Cannot GET /v1/i-dont-exist","status":404}`,

will need to become

expectedBody: `{"detail":"Cannot GET /v1/i-dont-exist","status":404,"title":"Not Found"}`,

and so on. Lots of little manual changes in the expected body values. I'll also need to add a check for empty details, because some tests are failing due to details: "" being included in the response.
I can do those manual changes in the tests, but it'll take some time so I'll need to come back to it later today or tomorrow.

Yeah, this is painful and a shortcoming of our tests. Ideally we should have a helper method in tests that transforms the expected string and the result into something comparable, despite the order of the fields - preferably with a pretty printed output of the differences. I don't know if there's already a library doing that or we need do write it ourselves.

There's also validationFunc, but it's way more boilerplate. We kinda experimented a different approach in #91, but I don't see it as a huge improvement.

Maybe we can adapt the strings for this PR as a short term solution, but work on that helper function as a long term one.

Also, I went ahead and upgraded gofiber to v2.51. Doesn't seem to introduce any breaking changes, so I assume that's fine? I didn't check the gofiber upgrade very thoroughly; I would understand if that needs to be a separate PR though.

It's perfectly fine, as that's the version introducing application/problem+json. It keeps this PR atomic.

Our extensive tests + the semantic versioning of gofiber should be enough.

PS. the linter workflow should now pass (#228)

@richardrdev
Copy link
Contributor Author

Okay, checks are passing now, I believe this is good to go.

One note - currently I have the detail property always added to the error response, even if it's empty, while validationErrors is only being added to responses where its non-nil. That's fine and works, but for consistency, would we instead want to always include validationErrors, and just have it be blank when it's not relevant? Would make the end of CustomErrorHandler a bit cleaner, and the tests would be easy to update to match. I can add that before the PR is merged if you like, just let me know. Not super important either way imo, I think it'd just be a bit cleaner.

Comment on lines 56 to 71
if problemJSON.ValidationErrors != nil {
err = ctx.JSON(fiber.Map{
"title": problemJSON.Title,
"detail": problemJSON.Detail,
"status": problemJSON.Status,
"validationErrors": problemJSON.ValidationErrors,
}, "application/problem+json")
} else {
err = ctx.JSON(fiber.Map{
"title": problemJSON.Title,
"detail": problemJSON.Detail,
"status": problemJSON.Status,
}, "application/problem+json")
}

return err
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can simplify this and have JSON be serialized with the rules specified in ProblemJSON's struct fields, as we already have those: https://github.com/italia/developers-italia-api/blob/main/internal/common/problem_json.go#L7-L13

Something like:

Suggested change
if problemJSON.ValidationErrors != nil {
err = ctx.JSON(fiber.Map{
"title": problemJSON.Title,
"detail": problemJSON.Detail,
"status": problemJSON.Status,
"validationErrors": problemJSON.ValidationErrors,
}, "application/problem+json")
} else {
err = ctx.JSON(fiber.Map{
"title": problemJSON.Title,
"detail": problemJSON.Detail,
"status": problemJSON.Status,
}, "application/problem+json")
}
return err
return ctx.JSON(problemJSON, "application/problem+json")

@bfabio
Copy link
Member

bfabio commented Mar 1, 2024

Okay, checks are passing now, I believe this is good to go.

One note - currently I have the detail property always added to the error response, even if it's empty, while validationErrors is only being added to responses where its non-nil.

I think not having the property (ie. setting it to nil) better reflects what we want to convey: there's no data for that field.

@richardrdev
Copy link
Contributor Author

Ah, thanks for linking the struct definition Fabio, I didn't realize the values had omitempty. That makes this much easier. Changed most of the test expectedBody values back. this method seems to use the original ordering. Will probably take a look at improving the expectedBody test matching as discussed.

Anyway, I believe this is done now, thanks for the help.

Fixes issue #225

@bfabio
Copy link
Member

bfabio commented Mar 2, 2024

Nice job @richardrdev, thanks!

@bfabio bfabio merged commit e610b03 into italia:main Mar 2, 2024
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants