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

execute: Forbid to return null from serialize function #3231

Merged
merged 1 commit into from
Aug 11, 2021

Conversation

IvanGoncharov
Copy link
Member

Fixes #1579

@IvanGoncharov IvanGoncharov added the PR: breaking change 💥 implementation requires increase of "major" version number label Aug 11, 2021
@IvanGoncharov IvanGoncharov merged commit 0fef3c4 into graphql:main Aug 11, 2021
@IvanGoncharov IvanGoncharov deleted the pr_branch branch August 18, 2021 09:06
@yaacovCR
Copy link
Contributor

@IvanGoncharov I know a while back, but doesn’t this change (as opposed to #1579) raise field errors for null leaf values even when the types are nullable?

spec reference: first sentence here https://spec.graphql.org/draft/#sec-Non-Null.Result-Coercion

@IvanGoncharov
Copy link
Member Author

@yaacovCR It's forbidden by the spec here:
https://spec.graphql.org/draft/#sel-IANRLHHCDCECCGgB2xE

@IvanGoncharov
Copy link
Member Author

IvanGoncharov commented Dec 18, 2021

@yaacovCR Null is separate from scalars, they are not converted to/from scalars.
Because it would cause them to not be reversable.

@yaacovCR
Copy link
Contributor

Thanks for quick response!

Ah, a reminder that nullable means that null is allowed/valid in response (does not cause error to bubble up), not that it’s actually not an error, which it sometimes isn’t (composite types) and sometimes is (for leaf values).

Makes sense in intent and practice now, appreciated!

@yaacovCR
Copy link
Contributor

I guess the error message should be “non-null” value not “non-nullable”.

@IvanGoncharov
Copy link
Member Author

I guess the error message should be “non-null” value not “non-nullable”.

@yaacovCR It also includes undefined since it is nullable in JS (undefined == null).

@yaacovCR
Copy link
Contributor

I still think that’s a bit wrong grammar wise.

Undefined is not “nullable” . It’s not anything able, it’s just a set value, we could say the return value of serialize is not nullable if the parameter is not null, so it can’t return x value, but we can’t say the expected return value itself is a non nullable value.

anyway it’s splitting hairs, thanks for explaining!!!!

@ephemer
Copy link

ephemer commented May 16, 2024

Hey @IvanGoncharov this PR changes behaviour that we've been relying on since 2017. We just ran into it by upgrading to Apollo Server 4, which uses graphql 16.x.

Basically we have a Scalar that – in serialize – looks to see if one of the object keys it was provided is null, and returns null in that case. We use this scalar in hundreds of places across our Schema, so pre-processing the value that is passed into serialize is not a good option.

    serialize({ relativeUrl, requestLocation } = {}) {
        if (!relativeUrl) {
            // allow for nullable ResourceURLs
            return null;
        }

        if (!requestLocation) {
            throw new Error("You must pass the user `requestLocation` when resolving ResourceURL");
        }

        return getResourceUrl(relativeUrl, requestLocation); // a string
    },

With the above we could just return { relativeUrl: null, requestLocation } for a nullable ResourceURL (the scalar type) and it will work fine. That is longer the case.

Can you think of a workaround?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
PR: breaking change 💥 implementation requires increase of "major" version number
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants