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

Names must not start with two underscores __ #743

Open
qwerdenkerXD opened this issue Nov 15, 2023 · 6 comments
Open

Names must not start with two underscores __ #743

qwerdenkerXD opened this issue Nov 15, 2023 · 6 comments
Labels
apollo-compiler issues/PRs pertaining to semantic analysis & validation bug Something isn't working

Comments

@qwerdenkerXD
Copy link

Description

The Specification declares the following:

# Reserved Names
Any Name within a GraphQL type system must not start with two underscores "__"
unless it is part of the introspection system as defined by this specification.

Currently, this is not satisfied by [email protected] and has been forgotten in PR #713

Steps to reproduce

Validate the following schema which has some of such invalid names defined:

type Query {
  __field(__arg: __MyScalar!): __MyType!
}

type __MyType {}

interface __MyInterface {}

scalar __MyScalar

enum __MyEnum {
  __EnumValue
}

union __MyUnion = __MyType | __Schema

input __MyInput {
  __field: __MyScalar!
}

Here a code sample.

Expected result

The validation should fail and have some respective diagnostics.

Actual result

The validation succeeds.

Environment

  • Operating system and version: Ubuntu 20.04.6 LTS
  • Shell (bash/zsh/powershell): zsh
  • apollo-rs crate: apollo-compiler
  • Crate version: 1.0.0-beta.6
@qwerdenkerXD qwerdenkerXD added bug Something isn't working triage labels Nov 15, 2023
@goto-bus-stop
Copy link
Member

Name also represents introspection names, so it's intentional that it supports underscores. We should handle this in validation, though!

@goto-bus-stop goto-bus-stop added apollo-compiler issues/PRs pertaining to semantic analysis & validation and removed triage labels Nov 15, 2023
@SimonSapin
Copy link
Contributor

SimonSapin commented Nov 28, 2023

I think we could check this either:

  • In various .validate() methods, under if file_id != BUILT_IN for introspection names. I believe so far we don’t have validation rules that need to find every single Name, so we’ll need to be careful not to miss some of them in various parts of data structures.
  • When converting from CST to AST, under if file_id != BUILT_IN. This requires adding the ability for this conversion to emit parse errors. (Currently it relies on apollo-parser having emitted all relevant errors.)
  • In apollo-parser’s lexer, with a new allow_builtin_names configuration

I have a mild preference for the lexer, since that’s where we check other aspects of Name syntax

@SimonSapin
Copy link
Contributor

I wrote the above with the incorrect assumption that every single Name anywhere in a document would need checking. The spec phrasing isn’t great but I think the spirit of it is about definitions that introduce a new named thing in a type system. So yes, checking in Schema::validation makes more sense.

@qwerdenkerXD
Copy link
Author

spec-ref
sounds like everything to me. So including it in executables is also necessary.
But I agree to check only for definitions, as you aren't able to refer to such definitions anyway if you can't define them.

@SimonSapin
Copy link
Contributor

The reserved name bit of spec does say "Any Name within a GraphQL type system" though. Type system being a schema. 🤔

@qwerdenkerXD
Copy link
Author

oh, my bad, you're right.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
apollo-compiler issues/PRs pertaining to semantic analysis & validation bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants