Skip to content

Conversation

@ajwerner
Copy link
Contributor

Fixes #522

Copy link
Member

@tomhoule tomhoule left a comment

Choose a reason for hiding this comment

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

Good catch. Thanks for the fix!

@tomhoule tomhoule merged commit 5f8c172 into graphql-rust:main Feb 11, 2025
10 of 11 checks passed
@danieleades
Copy link
Contributor

this was merged with failing CI jobs, will need to be fixed in a new PR to get the builds passing again

@Sytten
Copy link
Contributor

Sytten commented Jun 27, 2025

This broke a bunch of stuff and needs to be reverted or improved:

`?` operator cannot convert from `std::string::String` to `std::vec::Vec<std::string::String>`
expected struct `std::vec::Vec<std::string::String>`
   found struct `std::string::String`
= note: `?` operator cannot convert from `std::string::String` to `std::option::Option<std::vec::Vec<std::string::String>>`
   = note: expected enum `std::option::Option<std::vec::Vec<std::string::String>>`
            found struct `std::string::String`

@tomhoule tomhoule mentioned this pull request Dec 8, 2025
@emilbonnek
Copy link

emilbonnek commented Dec 8, 2025

@tomhoule,
I’ve just upgraded to 0.15.0, and I’m running into what looks like a similar issue to the above:

error[E0308]: `?` operator has incompatible types
 --> myfile.rs:8:10
  |
8 | #[derive(GraphQLQuery)]
  |          ^^^^^^^^^^^^ expected `Option<Vec<String>>`, found `String`
  |
  = note: `?` operator cannot convert from `std::string::String` to `std::option::Option<Vec<std::string::String>>`
  = note: expected enum `std::option::Option<Vec<std::string::String>>`
           found struct `std::string::String`
  = note: this error originates in the derive macro `GraphQLQuery` (in Nightly builds, run with -Z macro-backtrace for more info)

My query looks like this:

mutation FileDelete($input: [ID!]!) {
    fileDelete(fileIds: $input) {
        deletedFileIds
        userErrors {
            field
            message
        }
    }
}

and my macro like this:

#[derive(GraphQLQuery)]
#[graphql(
  schema_path = "schema.json",
  query_path = "myfile.graphql",
  variables_derives = "Debug, Clone",
  response_derives = "Debug, Clone",
  skip_serializing_none
)]

I’ve been digging into it for a while, but I haven’t been able to find a workaround.
Do you know if the concern raised earlier by @Sytten was addressed before the release, or if this might have been an unintended regression? It’s also possible there’s just a breaking change I haven't understood. Any guidance would be appreciated.

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.

codegen: breaking change for ID! types

5 participants