Note: the Swift initializer doesn't duplicate __typename in the ResultMap, so I'm not sure if this causes any serious issues, just thought I'd share.
apollo-ios version: 0.36.0
query:
query Something {
user {
...basicUser
}
}
fragment basicUser on User {
id
}
let codegenOptions = ApolloCodegenOptions(
codegenEngine: .default,
includes: "./**/*.graphql",
mergeInFieldsFromFragmentSpreads: true,
namespace: nil,
omitDeprecatedEnumCases: true,
outputFormat: .multipleFiles(inFolderAtURL: targetOutputUrl),
customScalarFormat: .passthrough,
urlToSchemaFile: schemaUrl
)

Interesting - is this new behavior to 0.36.0+? Looking at the changelog, there hadn't been any changes to the CLI for a while until 0.37.0.
Also worth knowing: Does this happen when __typename is explicitly specified as a field that should be fetched either on a fragment or on a particular query, or is this happening without that?
I'm just switching to the Swift Codegen library so I'm not sure if this is a new issue or not. It appears to duplicate __typename with all combinations of__typename being added / omitted to the query and fragment (not explicitly in fragment or query, in fragment but not query, in query but not fragment, and in both query and fragment).
Issue is present in 0.38.3 as well
So that's presently calling through to the same underlying typescript CLI (we're working on the actual swift-based codegen now), so it shouldn't be anything related to that.
At a certain point, though, if this isn't actively causing problems, it may not be worth trying to hunt it down as we're working on transitioning off the old codegen. The only thing I can think of is mayyyybe it might mess with the cache, but @martijnwalraven would know that one better than I do. Martijn, any thoughts on what the hell is going on here and whether it's worth it to investigate deeper?
That's a known issue that's been in there for a long time. It doesn't have any real effect because we merge fields as part of GraphQL execution. So the only issue is that we generate slightly larger code. We should be able to fix this with the new codegen though.
Good to know it shouldn't affect anything, I'll turn on that flag for my builds going forward now. Thanks for the explanation! This is resolved for me so I'll close the issue but feel free to reopen if you want to keep tracking it here.
Fair enough - I'd like to think this is a big enough bug that it should jump out pretty clearly