Warning "Function call causes an infinite recursion" for mocks which are of an unused ParentType.

[scottasoutherland]

Summary

When generating code for a type which is only used in a union, but is never actually queried, a mock is generated for that type which has an initializer that calls itself and generates an infinite recursion, and gets an xcode warning saying such "Function call causes an infinite recursion"

Version

1.0.5

Steps to reproduce the behavior

Have a Schema Such as

type TypeOne { 
   myProperty:  Int!
}

type TypeTwo { 
   secondProperty: Int!
}

type TypeThree { 
   thirdProperty: Int!
}

union MyType =
    TypeOne |
    TypeTwo |
    TypeThree
   

and a query that includes a fragment such as

fragment responseFields on MyType {
    ... on TypeOne {
        myProperty
    }
    ... on TypeTwo {
       secondProperty
    }
}

Notice the query does not have any selection for "TypeThree". Generate the Code & Mocks for the schema. Notice that you get a mock such as

public extension Mock where O == TypeThree {
  convenience init(
  ) {
    self.init()
  }
}

That causes the warning Function call causes an infinite recursion because the init calls itself as there are no properties passed to the initializer.

Logs

No response

Anything else?

No response

[scottasoutherland]

I know the easy work around here, is to remove that type from the schema because it is unused. However in my case, that is difficult, because we have multiple targets that use the same schema but query it in different ways, and some use the other types, and some do not.

[calvincestari]

Hi @scottasoutherland, can you please verify that you're using the latest version, and latest CLI. This bug was fixed in #2634 and released in 1.0.4.

The test case that was created to verify that PR fix is still passing and I've tried to replicate the build error using the types and fragment you mentioned above but I do not get the convenience initializer generated, which is expected from the previous fix.

If you are indeed on a version > 1.0.4 it would be helpful if you are able to reproduce the error in a standalone project we could then take a look at. Right now I cannot reproduce the error though.

[scottasoutherland]

Ah, indeed. Our main project which uses apollo was on 1.0.5, but our code generation project was on 1.0.3, this was fixed when upgrading. Thank you.

[calvincestari]

From 1.0.5 onwards there is a version check in the CLI that will warn you off mismatched versions between CLI and library.