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

@skip is not working when query has default value #2802

Closed
alexisbronchart opened this issue Jan 30, 2023 · 4 comments
Closed

@skip is not working when query has default value #2802

alexisbronchart opened this issue Jan 30, 2023 · 4 comments
Labels
awaiting response bug Generally incorrect behavior

Comments

@alexisbronchart
Copy link

alexisbronchart commented Jan 30, 2023

Summary

Fragments annotated with @skip are not included in the response when query has default value for the variable skip relies on.

Version

1.0.6

Steps to reproduce the behavior

Considering this query:

query SomeDetails(
  $id: ID!
  $skipFragment: Boolean = false
) {
  somedata(id: $id) {
    ...SomeFragment @skip(if: $skipFragment)
  }
}

and fetching it like so:

let skip = false
let query = SomeDetailsQuery(
    id: 42,
    skipFragment: .some(skip)
)
let response = try await apollo.fetch(query: query)

then response.somedata.fragment.someFragment will always be nil.
It used to work in 0.53.
If I change the skipFragment var definition from $skipFragment: Boolean = false to $skipFragment: Boolean! then it starts working again as expected.

Logs

No response

Anything else?

No response

@alexisbronchart alexisbronchart added bug Generally incorrect behavior needs investigation labels Jan 30, 2023
@AnthonyMDev
Copy link
Contributor

I think this is a duplicate of #2690, which has been fixed on the main branch by PR #2794. The next patch release will include this fix. You can rely on the main branch in the mean time!

@calvincestari
Copy link
Member

@alexisbronchart - please do retry your issue using the main branch. I'd like to know whether you're still having a problem using the fixed code from PR #2794; the conditional type looks to be exactly the same, i.e.: nullable.

@alexisbronchart
Copy link
Author

I can confirm the issue is fixed on main! Thanks!

@calvincestari
Copy link
Member

Great to hear. We've got a couple other issues we want to get out with 1.0.7 but it will be released very soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting response bug Generally incorrect behavior
Projects
None yet
Development

No branches or pull requests

3 participants