@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

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

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

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!

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

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).

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!!!!

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?