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

Fix non-null-list-of-non-null error when root data is nil #1259

Conversation

tamanugi
Copy link
Contributor

@tamanugi tamanugi commented Aug 3, 2023

Thanks for awesome library ✨

This PR is fix #1256

Copy link
Contributor

@benwilson512 benwilson512 left a comment

Choose a reason for hiding this comment

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

Hey @tamanugi thanks for taking a crack at fixing this!

This fix may be useful on its own, but it is not testing the scenario that the issue outlines. At a core level, the issue is about fields with return type non_null(list_of(:string)) but you are testing fields with return type non_null(list_of(non_null(:string))).

You need a test that uses field return type non_null(list_of(:string)) and exhibits the error message in the issue, that is then fixed by your changes.

Your change DOES fix a crash, which is great! This might be the same root cause as the crash described in the issue but since the return types don't match I'm not sure.

Please add in this test and we'll be good to go!

@tamanugi
Copy link
Contributor Author

tamanugi commented Aug 5, 2023

Hi @benwilson512 , Thanks for review ✨

You are right, the test should have been for non_null(list_of(:string)).

I have fixed the test 👍
556a8cc

@benwilson512
Copy link
Contributor

Hey @tamanugi thanks for your continued effort. I'm going to push some changes up I think that better distinguish between child and element. In the existing tests child refers to a subfield, not an item in the list. I think this ambiguity is making it difficult to determine which test is supposed to cover which scenario.

I'm not entirely convinced that this does the right thing for lists of nullable that return [nil] but I should be able to see that more clearly shortly.

test "list of non null things works when child is null" do
doc = """
{
nonNullListOfNonNull(makeNull: true) { __typename }
nonNullListOfNonNull(makeChildNull: true) { __typename }
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't see why this test is modified.

Copy link
Contributor

Choose a reason for hiding this comment

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

OH I see the semantics of make_null was changed.

@benwilson512
Copy link
Contributor

OK I see what you were doing now. In the future as a bit of advice for open source contributions please add some comments to the PR to explain why you're changing existing tests. I get why you did it now because we need to distinguish between making the whole field null vs making an element in the list null. However when PRs change existing tests it always complicates things cause I am not sure why existing test behavior would need to change.

@benwilson512
Copy link
Contributor

Right and the thing is if you're changing the argument name then you should change EVERY test that uses that argument because now they're testing different things.

Copy link
Contributor

@benwilson512 benwilson512 left a comment

Choose a reason for hiding this comment

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

Thanks for digging into this, glad we could get it in a good spot!

@@ -285,7 +285,21 @@ defmodule Absinthe.Phase.Document.Execution.Resolution do
|> propagate_null_trimming
end

defp maybe_add_non_null_error([], values, %Type.NonNull{of_type: %Type.List{}}) do
defp maybe_add_non_null_error([], nil, %Type.NonNull{}) do
Copy link
Contributor

Choose a reason for hiding this comment

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

Moved this up as this the most fundamental check, best to do it first.

maybe_add_non_null_error([], values, type)
end

defp maybe_add_non_null_error([], values, %Type.List{of_type: %Type.NonNull{}})
Copy link
Contributor

Choose a reason for hiding this comment

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

Before, this clause would happen for any non_null(list_of( regardless of wether the inner type was non_null or not. Now we check the inner type properly.

@benwilson512 benwilson512 merged commit cb7f309 into absinthe-graphql:master Aug 5, 2023
@tamanugi
Copy link
Contributor Author

tamanugi commented Aug 7, 2023

@benwilson512
Thanks for your follow-up and awesome advice✨
I have limited experience with OSS, so it was very educational for me.

@benwilson512
Copy link
Contributor

Thanks for your contribution!

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.

False positive error for non_null validation
2 participants