Skip to content

Using \r\n In GQL String Will Cause Invalid Swift Generation Using ApolloCLI #3553

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

Open
Nathan-Molby opened this issue May 7, 2025 · 2 comments
Labels
bug Generally incorrect behavior codegen Issues related to or arising from code generation good first issue Issues that are suitable for first-time contributors. low-priority

Comments

@Nathan-Molby
Copy link

Summary

With the following GQL schema:

schema {
  query: Query
}

type Query {
  test(test: String): TestType
}

type TestType {
  "Test\r\nTest\r\nTest\r\nTest"
  test: String 
}

And the following operation:

query Query {
  test(test: "Hello") {
    test
  }
}

Running the ./apollo-cli-generate will cause this Swift code to be generated:

extension MySchema {
  class Query: GraphQLQuery {
    static let operationName: String = "Query"
    static let operationDocument: ApolloAPI.OperationDocument = .init(
      definition: .init(
        #"query Query { test(test: "Hello") { __typename test } }"#
      ))

    public init() {}

    struct Data: MySchema.SelectionSet {
      let __data: DataDict
      init(_dataDict: DataDict) { __data = _dataDict }

      static var __parentType: any ApolloAPI.ParentType { MySchema.Objects.Query }
      static var __selections: [ApolloAPI.Selection] { [
        .field("test", Test?.self, arguments: ["test": "Hello"]),
      ] }

      var test: Test? { __data["test"] }

      /// Test
      ///
      /// Parent Type: `TestType`
      struct Test: MySchema.SelectionSet {
        let __data: DataDict
        init(_dataDict: DataDict) { __data = _dataDict }

        static var __parentType: any ApolloAPI.ParentType { MySchema.Objects.TestType }
        static var __selections: [ApolloAPI.Selection] { [
          .field("__typename", String.self),
          .field("test", String?.self),
        ] }

        /// Test
Test
Test
Test
        var test: String? { __data["test"] }
      }
    }
  }

}

As you can see, anything past the first \r\n is not commented, resulting in invalid syntax.

I've recreated this problem in this repo, which you can clone and run to reproduce yourself.

Version

1.21.0

Steps to reproduce the behavior

See above.

Logs

Anything else?

No response

@Nathan-Molby Nathan-Molby added bug Generally incorrect behavior needs investigation labels May 7, 2025
@calvincestari
Copy link
Member

Hi @Nathan-Molby, thanks for creating the issue. You're right, this looks like a bug interpreting multiline characters in a single-line documentation comment.

This is a low priority issue to fix though so for now the recommended workaround is to use the Block String sequence ("""). You can either leave the escaped characters in there to preserve them in the generated code or use an actual multiline documentation comment for prettier formatting.

@calvincestari calvincestari added codegen Issues related to or arising from code generation low-priority and removed needs investigation labels May 7, 2025
@Nathan-Molby
Copy link
Author

Thanks @calvincestari . The schema I'm actually using is generated from a multiline C# GQL comment like this:

public class Query {
    [GraphQLDescription("""
        abc
        def
        """)]
    public string GetApplicationName() => "app";
}

We're using Chilicream to generate the GQL documentation, and there is a related issue here on their side to convert the automated documentation to use the block string that you mentioned, but it appears to be closed and not finished.

For now (since this only affects one field), I can manually edit the fetched schema to change the description, but would love to see this fixed so I don't have to do that on every fetch.

@AnthonyMDev AnthonyMDev added the good first issue Issues that are suitable for first-time contributors. label May 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Generally incorrect behavior codegen Issues related to or arising from code generation good first issue Issues that are suitable for first-time contributors. low-priority
Projects
None yet
Development

No branches or pull requests

3 participants