Hello :wave: Is it possible to attach an arbitrary...

# apollo-kotlin

[wasyl]

Hello 👋 Is it possible to attach an arbitrary object as a tag to an Apollo call, so that the tag can be read in an okhttp3.Interceptor class? The goal is to pass an object when triggering an Apollo call, and read it later from okhttp3.Request#tag() in the interceptor.

There’s https://github.com/apollographql/apollo-kotlin/issues/2527 so I assume there isn’t (though maybe something appeared in v3?) and that the only way to do that now is to set a request header, read it in the interceptor, and strip before sending to the server?

[mbonnin]

You can use ApolloCall.addExecutionContext() with your own context

[wasyl]

Ah, I thought there was something in v3 🙂 We’re waiting for https://github.com/apollographql/apollo-kotlin/issues/3774 before we update to v3 but that’s ok 🙂 Thanks!
Btw let me know if there’s a chance #3774 will be fixed relatively soon or if we’re better off adding manual `__typename`s for the time being. We don’t mind waiting a bit, but also would rather migrate sooner than later 🙂

[mbonnin]

Yea sorry, that one's on me. I haven't had the opportunity to work as much as I wanted on this last week but it's still on top of the todo list

[wasyl]

No worries, just wanted to clarify the prioritization 🙂

[Stylianos Gakis]

Just wondering @wasyl if you’ve gone through the migration and what approach you took to this. I’m also trying to get back to finishing this migration and I now have ~300 errors and I am not looking forward to adding them all individually 😅
I do however think that all of the references I got are for some test data and not production code, so I am guessing I could add __typename = "" to all of them right? If this is not in production code it should be fine?
With that said, if it does end up in production code, what does this break exactly? Not so proficient in the GraphQL spec tbh 😅

[wasyl]

Not sure quite honestly, I’m gonna ping @mateusz.kwiecinski who leads the migration on our end (although https://github.com/apollographql/apollo-kotlin/issues/3774 is still in progress and I’m not sure if it’ll change anything wrt how typename fields are created/handled). I’m somewhat sure we removed some of our test models, as our tests mostly use prerecorded json responses anyway

[mateusz.kwiecinski]

☝️ What Lukasz said. During the migration Instead of adding __typename I removed all of the models we had in favor of more functional tests with pre-recorded jsons.
If you prefer keeping models then maybe https://www.apollographql.com/docs/kotlin/testing/test-builders/ could help here?
According to the documentation

They automatically populate the __typename field and deduplicate merged fields whenever possible.

if it does end up in production code, what does this break exactly?

If you have queries structured like this it will cause cache misses. (basically you can’t reliably watch the cache due to missing __typename , and depending on your configuration, if there is an active watcher already it’ll trigger refetch fetcher to make additional network call to fetch the missing __typename value)
Our app heavily relies on valid cache so the 3774 is a blocker for us, we’re still on 2.x

[Stylianos Gakis]

Yeah I’ve thought of replacing everything with the test builders but it’s like hundreds of them, probably would rather work around it atm, but you’re probably right that it’s the best approach.

I think I’ll try out just using “” as the typename for now to make everything build again, and I’ll see if this breaks stuff. Then maybe patch some of those places by looking at what the builders use for typename and copy that (Or is the important part that it’s just consistent? Like adding “foo” instead would still work as long as it’s consistent right) and if not just go straight to the builders.

The way we use this in our code-base is a bit unique I guess, we have a bunch of builders that we use in places like here and we use those models to pass to the UI in an “Engineering Mode” (notice how this is all under a testdata module, not used in production) version of the app we have where you can look browse like a list of possible cases at how screens would look like with different configurations and we use those builders to setup these different scenarios. We also use them for tests though sometimes so there I might have to be a bit more careful.
This is a bit irrelevant to my question but I just thought I’d give you some context as to why I am asking the question in the first place 😄

[wasyl]

There’s good chance that https://github.com/apollographql/apollo-kotlin/issues/3774 will also reduce the number of generated typename fields for you significantly. Depending on your schema it might be most models (for us it’s almost everything). But overall what can break with wrong typename is caching, so if you’re only using the models statically for tests then having some empty typename shouldn’t be a big deal

[Stylianos Gakis]

Nice, yeah it’d reduce them by a bunch for us too. Thanks a lot for your input!