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: Validate GraphQL schemas #3152

Merged
merged 5 commits into from
Oct 18, 2024

Conversation

nasdf
Copy link
Member

@nasdf nasdf commented Oct 17, 2024

Relevant issue(s)

Resolves #3151

Description

This PR fixes an issue where GraphQL schemas were never validated.

Tasks

  • I made sure the code is well commented, particularly hard-to-understand areas.
  • I made sure the repository-held documentation is changed accordingly.
  • I made sure the pull request title adheres to the conventional commit style (the subset used in the project can be found in tools/configs/chglog/config.yml).
  • I made sure to discuss its limitations such as threats to validity, vulnerability to mistake and misuse, robustness to invalidation of assumptions, resource requirements, ...

How has this been tested?

Updated integration tests.

Specify the platform(s) on which this was tested:

  • MacOS

@nasdf nasdf added the bug Something isn't working label Oct 17, 2024
@nasdf nasdf added this to the DefraDB v0.14 milestone Oct 17, 2024
@nasdf nasdf self-assigned this Oct 17, 2024
jsimnz

This comment was marked as duplicate.

Copy link
Member

@jsimnz jsimnz left a comment

Choose a reason for hiding this comment

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

LGTM (super speedy)

Copy link

codecov bot commented Oct 17, 2024

Codecov Report

Attention: Patch coverage is 97.82609% with 4 lines in your changes missing coverage. Please review.

Project coverage is 78.00%. Comparing base (e81133e) to head (10535d3).
Report is 1 commits behind head on develop.

Files with missing lines Patch % Lines
internal/request/graphql/schema/manager.go 78.95% 3 Missing and 1 partial ⚠️
Additional details and impacted files

Impacted file tree graph

@@             Coverage Diff             @@
##           develop    #3152      +/-   ##
===========================================
- Coverage    78.08%   78.00%   -0.09%     
===========================================
  Files          353      354       +1     
  Lines        34661    34660       -1     
===========================================
- Hits         27065    27034      -31     
- Misses        5978     6001      +23     
- Partials      1618     1625       +7     
Flag Coverage Δ
all-tests 78.00% <97.83%> (-0.09%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
internal/db/schema.go 84.81% <100.00%> (ø)
internal/db/view.go 64.59% <100.00%> (ø)
internal/request/graphql/parser.go 86.57% <100.00%> (-0.76%) ⬇️
internal/request/graphql/schema/collection.go 84.64% <ø> (-5.08%) ⬇️
internal/request/graphql/schema/schema.go 100.00% <100.00%> (ø)
internal/request/graphql/schema/types/types.go 100.00% <100.00%> (ø)
internal/request/graphql/schema/manager.go 88.46% <78.95%> (-9.98%) ⬇️

... and 16 files with indirect coverage changes


Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e81133e...10535d3. Read the comment docs.

@nasdf nasdf requested a review from a team October 17, 2024 16:34
Copy link
Member

@shahzadlone shahzadlone left a comment

Choose a reason for hiding this comment

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

Nice and clean! Thanks Keenan =)

explainEnum,

indexFieldInput,
validation := gql.ValidateDocument(&s.schema, doc, gql.SpecifiedRules)
Copy link
Contributor

@AndrewSisley AndrewSisley Oct 17, 2024

Choose a reason for hiding this comment

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

thought: I love the near total lack of documentation in the gql-go lib...

todo: This is quite an odd flow, as we appear to be validating the doc against an s.schema that does not yet contain the contents of doc. Can you please document this call quite heavily.

Copy link
Member

Choose a reason for hiding this comment

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

I think you have the validation flow backwards Andy.

The ValidateDocument call is to validate that the given SDL document is valid relative to the schema defined up till now (eg, first run only the "default" schema is defined).

This is the correct flow as I understand it. A comment can help but it doesn't seem unusual or out of place to me.

Copy link
Contributor

Choose a reason for hiding this comment

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

The ValidateDocument call is to validate that the given SDL document is valid relative to the schema defined up till now (eg, first run only the "default" schema is defined).

That's fine, but need to be documented, particularly given that the SDL is partial atm and does not fully represent the changes that will be made to the GQL-schema once encorporated. There is a lot of GQL stuff that we do/add that will not be validated by this call.

Copy link
Member

Choose a reason for hiding this comment

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

Agreed, all the generated stuff after this won't get validated, but I don't think there's any implication at this call site that it's doing anything more than validating the user provided SDL, which needs to be valid on its own before continuing on with any future schema generation stuff.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, I'm totally on board with all of that.

The reason I'm asking for documentation is so that the next person who comes across this line (including our future selves) doesn't need to think terribly hard about why it is done here, and why the premature validation is okay here (and potentially come to the wrong conclusion, wasting even more time and thought).

Copy link
Member Author

Choose a reason for hiding this comment

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

I've added documentation that hopefully makes it a bit more clear as to what's happening

Copy link
Contributor

Choose a reason for hiding this comment

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

Looks good, thanks Keenan - should help a fair bit :)

Copy link
Contributor

@AndrewSisley AndrewSisley left a comment

Choose a reason for hiding this comment

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

It looks good, but the location of the ValidateDocument looks odd and needs documentation.

thought: You blended a lot of seemingly random refactors into to main change, without documenting them in the PR description or committing them separately - whilst they are nice changes, presenting them to reviewers like this made the review quite a lot harder than it needed to be.

@nasdf
Copy link
Member Author

nasdf commented Oct 17, 2024

It looks good, but the location of the ValidateDocument looks odd and needs documentation.

thought: You blended a lot of seemingly random refactors into to main change, without documenting them in the PR description or committing them separately - whilst they are nice changes, presenting them to reviewers like this made the review quite a lot harder than it needed to be.

Sorry it was a bit messy. I put this PR together very quickly last night and should have probably just waited to finish it properly.

Copy link
Contributor

@AndrewSisley AndrewSisley left a comment

Choose a reason for hiding this comment

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

Sorry it was a bit messy. I put this PR together very quickly last night and should have probably just waited to finish it properly.

No worries at all, it was a small PR after all, and I'm plenty guilty of rushing stuff out in the evenings :)

Looks great, and is great to get this in, especially before the release :)

explainEnum,

indexFieldInput,
validation := gql.ValidateDocument(&s.schema, doc, gql.SpecifiedRules)
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks good, thanks Keenan - should help a fair bit :)

@nasdf nasdf merged commit 8181a15 into sourcenetwork:develop Oct 18, 2024
43 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Validate GraphQL schemas
4 participants