`GraphQLQuery` derive: `?` operator expects `Option<Vec<String>>` but receives `String` (0.15.0)

[emilbonnek]

After upgrading to 0.15.0, I’m encountering a type mismatch generated by the GraphQLQuery derive macro that appears similar to the issue previously raised in #523.

Error

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)

GraphQL mutation

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

Rust macro usage:

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

Schema download:

graphql-client introspect-schema https://shopify.dev/admin-graphql-direct-proxy/2026-01 > packages/lib_shopify_graphql/src/schema.json

Description

The generated code seems to attempt to use the ? operator on a String where the surrounding context expects an Option<Vec<String>>. This matches the pattern described by @Sytten in #523. I also commented in there, but I figured its better with a separate issue.

I am happy to provide anything like expanded macro outputs or the schema file or whatever can help debug this.

Expected behavior

The derive macro should generate code that correctly matches the schema types (in this case: a non-null list of non-null IDs). Earlier versions did not produce this mismatch. This is the only issue I have had after atempting to upgrade to 0.15.0.

EDIT:
Added command to introspect schema for the example.

[Sytten]

Check #543. This lib is semi maintained and I dont have time to maintain another lib.

[emilbonnek]

@Sytten
Thanks, just so you know I didn’t mean to imply that you should take on the maintenance. I only tagged you because you had previously described the same error. I sadly don’t know enough about Rust macros or GraphQL internals to really understand what’s going on here.

Since there was a release just a few days ago, I’m hoping the lib isn’t completely unmaintained. Maybe @tomhoule can help confirm whether this error I am getting is an intentional change or something that slipped through?

[tomhoule]

Most likely something that slipped through. I'd treat it as a bug and release a patch version.

[emilbonnek]

Is there anything I can do to help move this toward a patch release? I’m not really able to contribute macro fixes directly, but I’m happy to gather whatever info or examples you need.

[tomhoule]

I don't know if I'll be able to work on it myself, but for anybody working on it, a minimal reproduction example would for sure be a huge help. I think only the schema is missing, with the information in your post.

[emilbonnek]

My example is from a Shopify query. Their latest schema can be introspected like so:

graphql-client introspect-schema https://shopify.dev/admin-graphql-direct-proxy/2026-01 > schema.json

That will work with the example I gave before. I also edited the issue itself to include this.

---

If I give it a shot would you have the time to review and do the patch release if its okay? Or is there some other maintaner I could ask to help? I only pinged you originally because you did the last release a couple of weeks ago which included the bug.

[Sytten]

Honestly the patch is very simple if we revert the support for int, otherwise the patch is already done in my branch to properly support both in #543
I just dont have time to do it

[emilbonnek]

I looked into the history of this issue and wanted to suggest a path forward. First, I want to acknowledge that both of you have mentioned limited bandwidth for maintenance on this library, and I absolutely respect that. I’m genuinely trying to ask as little of your time as possible.

The History (As I Understand It)

1. Aug 2023 - Issue Deserializing ID as integer not String #455 requested integer ID deserialization support

   • @Sytten noted that this was "a bad idea" and risky long-term since IDs are meant to be opaque per spec

2. Jan 2025 - PR codegen: enable ids to be deserialized from strings or integers #476 was merged, adding integer ID support despite the earlier concerns

3. June 2025 - Issue ID Deserialization is broken for Vec #542 was reported by @Sytten

   • The integer ID feature broke Vec<ID> and Option<Vec<ID>> deserialization
   • @Sytten commented: "The integer ID parsing IMO should not have been merged at all"

4. June 2025 - PR Properly handle integer id #543 was opened by @Sytten to properly handle both types

   • @tomhoule replied: "I think we should consider removing integer ID deserialization support" and "Let's do that"
     (https://spec.graphql.org/draft/#sec-ID)

5. Dec 2025 - Issue GraphQLQuery derive: ? operator expects Option<Vec<String>> but receives String (0.15.0) #559 (this issue) same Vec<ID> breakage reoccurring

---

Is this understanding correct?

And @tomhoule, do you still feel that removing integer ID support is the right approach? If so, I’d be happy to try putting together a PR that reverts the integer ID changes introduced in PR #476.

Alternatively, if you prefer to keep integer support and move forward with PR #543, that works too. I just want to confirm the direction before investing time, and ideally avoid working on something that won’t have someone available to review or eventually release it.

[tomhoule]

Yes, let's revert that.

[tomhoule]

The new 0.16.0 release is out with the fix. Thanks for reporting and fixing!