Nested input types generate an error at introspection time

[djc]

I have some types like this:

#[derive(InputObject)]
pub(super) struct EditDomainInput {
    domain: String,
    title: Option<String>,
    name: Option<String>,
    description: Option<String>,
    logo: Option<String>,
    contact_info: Option<ContactInfo>,
}

#[derive(InputObject)]
pub struct ContactInfo {
    address: Option<Address>,
    phone_number: Option<String>,
    payment_url: Option<String>,
    contact_email: Option<String>,
}

#[derive(InputObject)]
pub struct Address {
    country: Option<String>,
    region: Option<String>,
    city: Option<String>,
    postal_code: Option<String>,
    street_address: Option<String>,
}

This compiles fine and I can generate SDL from it.

Expected Behavior

Introspection queries against this schema should work.

Actual Behavior

Introspection query fails; error from GraphiQL:

Introspection must provide input type for arguments, but received: ContactInfo.

Specifications

• Version: 3.0.36
• Platform: macOS
• Subsystem: input types

[sunli829]

I can't reproduce it, can you provide a repository that reproduces this issue? 😁

[djc]

Here's a full reproducer: https://github.com/djc/nested-input.

What I find really surprising about this is that introspection works okay as long as I comment out the _input argument to the _edit_foo() mutation.

[sunli829]

Info is both an input type and an output type causing this error.

#[derive(InputObject)]
#[graphql(name = "InfoInput")] // Add this attribute to rename the input type name
pub struct Info {
    email: Option<String>,
}

[sunli829]

This error cannot currently be reported at compile time, I will add a runtime check. 🙂

[djc]

Why can't Rust types implement both the input and the output traits?

[sunli829]

This is not allowed in the GraphQL spec, they need to have different names.

[sunli829]

You can implement as input object and output object for the same Rust type, but for GraphQL they are actually different objects, so must have different names as well.

[djc]

Would be nice if there was a way to do this similar to the way currently multiple names can be declared depending on any generic type parameters.

[sunli829]

This should not be possible. 😂

[sunli829]

Or I don't know how to do it. 😄

[djc]

Actually, it seems like this is already possible? I can use #[graphql(name = "InfoInput")] with the derive(InputObject) to give the input side a different name in the GraphQL schema.

[sunli829]

Yes, procedural macros can do it.

[sunli829]

You mean, always automatically add the Input suffix?

[djc]

Ah, sorry -- I didn't actually mean that the macros should implicitly add a suffix to input type names. I meant that there should be a way for me to reuse the same type under a different name, but it looks like that already exists.

I think it might actually be nice if there was a way I could opt in to add Input suffixes to all input type names on a per-crate basis to prevent this issue from happening, but I could understand that you might not want to enable this by default.

[sunli829]

Well, I'm now going to add a runtime check that panics when the same Rust type has the same name.

[sunli829]

Released in v3.0.37