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
feat: set undefined on null input #2731
feat: set undefined on null input #2731
Conversation
const isUndefined = request[paramName] === undefined | ||
const ret = validatorFunction && validatorFunction(isUndefined ? null : request[paramName]) |
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 not 100% sure of this approach. I think it's good as we're explicitly passing null
indicating the absence of value instead of undefined
which only exists in JavaScript. Please, let me know your thoughts.
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.
What is this solving?
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.
Basically, if we set undefined
as the default value for an empty req body when running the schema validation, doesn't matter if the schema allows the body to be nullable, as we're passing undefined
the validation will throw right away. Changing from undefined
to null
allows those schemas which are nullable to validate and pass if the value it's empty (at least the body)
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 see. This is validating the value of path parameters. How can a path parameter be null? @Eomm what is your opinion here?
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.
For now yes, I can reduce it to only the body
for sure. I'll like to hear your opinion, maybe I'm missing something where there's a better way to handle it
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 function is called 4 times with the paramName
equals to params
, querystring
, headers
and body
(only in the case paramName===body
this check is needed if I have understood the case)
I saw there are some tests that cover this case already
I think this check is faster than a string compare so it LGTM
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.
We should add some tests to check:
- how to send an empty body response (is
reply.send()
working?) - send empty in sync and async context
- a notice in docs on how to deal with it
Answering your points 🙂
|
Is this new behavior? I genuinely cannot recall. I know there are codes like 204 that shouldn't even send an empty string. |
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.
It does, it's returning an empty string. Actually, I'm also wondering if it's expected when sending an empty body. Should we handle it differently?
I was wrong sorry, I was thinking of another PR 🤦
Sure, just let me know if I'm missing something, in all cases I'll update the docs based on all the comments for this PR
In the hook section there are a couple of hooks that say that the req.body
is null
(now undefined
).
const isUndefined = request[paramName] === undefined | ||
const ret = validatorFunction && validatorFunction(isUndefined ? null : request[paramName]) |
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 function is called 4 times with the paramName
equals to params
, querystring
, headers
and body
(only in the case paramName===body
this check is needed if I have understood the case)
I saw there are some tests that cover this case already
I think this check is faster than a string compare so it LGTM
I didn't check the behavior on 204, let me double-check it
No issues 😄
Working on it 👍 |
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
@jsumners when double-checking the behavior on 204, the response is sending an empty string as a response. Taking a look into other tests, like this one, we're basically just validating that the body it's empty, then I think this is expected. I added a new test just to cover that scenario. Sounds good? |
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
While this should be a bugfix, I agree that it might cause some disruption, so let's be safe and release it as a major.
* feat: handle empty body.payload as undefined * test: adjust tests to body === undefined * test: add tests for undefined req.body on 204 * docs: update docs for undefined as default
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Fixes #2618
On empty
body.payload
,undefined
is set instead ofnull
.Checklist
npm run test
andnpm run benchmark
and the Code of conduct