Hello hello! Got a doubt regarding apollo v4 exception handling and authentications 🧵

Hi! I'm trying to migrate over to the new normalized cache, having followed the docs for Relay-style pagination, but I'm getting a

NullPointerException

crash in

ConnectionMetadataGenerator.metadataForObject

that I'm having a hard time understanding 🧵

Hi All, I'm hoping i can get some pointers here to help with my issue. We're using

4..0.0

and have

autoPersistedQueries

enabled. We're also trying to use the

@defer

directives for some high-latency fields. Now the issue, whilst we can see in the logs the incremental data, e.g the attached, we are not able to capture this in the query response itself. I've pretty much logged everything I possible can, no errors and no deferred data. Any idea what I should try or where to look?

Would it be possible to add a flag to allow us to treat

UnusedVariable

as an error issue instead of just warning? I can file a github issue about this if folks feel it would be useful/make sense.

I've created my own compiler plugin, but now I would like to try the 'modern' normalized cache library and its cache plugin. The docs say to wrap the plugin and call them from a main plugin. Thats fine, I am happy to do that from my own compiler plugin and delegate some to the cache plugin. However, just the act of loading the dependency

api(libs.apollo.cache.plugin)

Results in the error: "Apollo: only a single compiler plugin provider is allowed" How am I supposed to wrap the plugin?

Hi Team, just giving the new

normalised-cache

a go as need the pagination feat however, im getting:

Unexpected JSON token at offset 153301: Encountered an unknown key 'scalarMapping' at path: $.normalizedPath
Use 'ignoreUnknownKeys = true' in 'Json {}' builder to ignore unknown keys.
JSON input: .....lizedPath":"schema.graphqls","scalarMapping":{},"generateDat.....

are there any docs/examples for how union types are treated in Apollo Kotlin?

Does anyone have a nice way to fake apollo query dataa in tests aside from creating them.. as in

val fakeQueryData = Query.Data(id = "blah" , name="steve")

ended up with a massing file of fakes for tests and was hoping there are some alternatives.

Hi Team! Any idea whats causing this runtime error: I'm using

com.apollographql.apollo:apollo-normalized-cache-sqlite

v4.0.0 which matches

apollo

version

Apollo: unhandled exception
java.lang.Exception: Unable to read a record from the database
at com.apollographql.apollo.cache.normalized.sql.SqlNormalizedCache.loadRecord(SqlNormalizedCache.kt:25)
Caused by: android.database.sqlite.SQLiteException: Can't downgrade database from version 3 to 1

I see:

NormalizedCache.remove(pattern: String)

is removed. Which is kind of ok, but it would be nice to have a convenience to remove all cache keys associated with a specific type (or cache key scope?), which assuming type was prefixed in the cache keys, was easy to do with this function

Have you all thought about supporting a compiler plugin for a client-side @defer solution? One obvious use case for us is that our GQL service is atm a lamda based GQL service which can't keep the connections open to support proper @defer yet. However, even assuming that's resolved, I don't love that a large GQL query would need to be sent to the server if a partial match is found, and would prefer to break it down into smaller queries that might be more reasonable to be sent together. Do you think I am thinking of GQL wrong in wanting to compose it this way?

I was looking over https://apollographql.github.io/apollo-kotlin-normalized-cache/migration-guide.html#cacheresolver-cachekeyresolver and I think it should include references to CacheControlCacheResolver and SchemaCoordinatesMaxAgeProvider

Me again - is there a good way to define a size threshold through directives where merging would be truncated during pagination? Or do we just have TTL based eviction rules?

Is there a way to share fragments between schemas? Where I work we have several services which draw from a common schema which define types we expect from frontend facing services. For example Service A has its own schema, Service B has its own schema, but they both feature type Foo {}. Ideally I’d like to have one fragment for Foo defined and shared across both, is this possible?

Is it possible to serialize or make Apollo Mutations or Input objects serializable? I would like to save the operations to disk and send them later.

Ever since I made my apollo schema module a KMP one, and moved the little code I noticed that my IDE no longer is able to resolve fields etc when I Cmd + B on them in my gql files. For reference, I link our setup to our schema here https://github.com/HedvigInsurance/android/blob/26e47ac09de88c6fc2dfd4aa6544c4930543b284/app/apollo/apollo-octopus-public/build.gradle.kts#L13-L14 And the schema itself now lives here under "commonMain" https://github.com/HedvigInsurance/android/blob/26e47ac09de88c6fc2dfd4aa6544c4930543b284/app/apollo/apollo-octopus-public/build.gradle.kts#L13-L14 Does the IDE plugin expect a different path somehow? Can I provide it with the correct path to start getting those smart features working again? When I look at settings: "Settings | Languages & Frameworks | GraphQL | Apollo Kotlin" I do not see any option for me to manually give it the path which is the last thing I tried in order to resolve this

Somewhat related to the message above. I've been just using the latest snapshot of the IDE plugin as a consequence of trying to work around the issue above. However now when using 4.3.2-SNAPSHOT.2025-07-27.7a171f0 all of my GQL files are basically red. I of course don't expect every snapshot build to be perfect, but would you say that it's expected that snapshot builds don't necessarily always work, since you may be in the middle of fixing between days or stuff like that? I can just revert to not using the snapshots and wait for the real release of the fix of the bug above if so, it would not be a problem for me. Just asking to know what the expectations are from the snapshot builds.

I am using Apollo Kotlin 4.3.1, and I'm not sure if this is intentional behavior or a bug, but here's the issue I'm running into (see 🧵): tl;dr server is violating schema nullability, still returns partial data and errors which are discarded by Apollo Kotlin in favor of returning an exception.

Question about potentially continuously re-running an apollo request on a loop while it does not return what I want it to, so I want to keep retrying 🧵

Are there known issues when attempting to use the generated data builders alongside custom scalar adapters? In our case, just enabling data builders with no other project changes, the Apollo (4.3.2) generated code fails to compile in several places where scalars should be getting mapped to a

String

.

I did find apollo support on Ktor, does anyone how to make queries in it? I cant find anything in documentation: https://apollographql.github.io/apollo-kotlin-ktor-support/kdoc/index.html Or is it better run regular Apollo for this?

we have a

CreateSomethingMutation

and a

SomethingQuery

(code in the thread) — they both return the same thing (semantically), but they're both different from each other in structure/arguments, which means this happens: •

CreateSomethingMutation

is called and we cache its result •

SomethingQuery

is then observed (cache only) but we then get a cache miss our current workaround is to manually get the result from the mutation and add it to the cache as if it was the result of the query, and then everything works fine, but this seems like a common scenario so I thought I'd check if there's any better way to handle this (e.g. tweaking somehow the graphql structure?)

When using Apollo Execution plugin for server, whats the correct way of injecting dependencies into it, is it to use ExecutionContext like this? https://github.com/paug/AndroidMakersBackend/blob/main/service/src/main/kotlin/androidmakers/service/Main.kt

private fun ApplicationCall.context(uid: String?): ExecutionContext {
    return AuthenticationContext(uid) + DatastoreContext(datastore) + CacheControlContext()
}

Will I then be able to get first parameter in my class methods that using @GraphQLQuery? Or do I need some kind of singleton holding all deps? I am trying to use Ktor server DI library, but I dont mind change to something else. Trying to structure my Apollo code better.

Disappointed to see the deprecation of CacheAndNetwork, but I kind of understand: https://github.com/apollographql/apollo-kotlin-normalized-cache/pull/205 I do understand chaining 2 states has limitations (what if you want CacheAndLocalDatabaseAndNetwork), etc too. this shorthand is helpful for our react native familiar engineers coming from apollo react client. Would be nice if it was possible to contribute our own fetch policies with their own set of execution options (or similar?)

Apollo parsing on a low end device has lots of non running blocks. is there any known explanation about it. The parsing also takes more time than actual network operation. What is the best practice to investigate something like this?

Hello 👋, we are seeing a few crashes around websockets. Stack trace in 🧵, I couldn't find this reported anywhere so wondering if something is wrong with our setup.

@mbonnin Hopefully quick question for you, do we have to guard against interceptors being called concurrently for different requests?

Hey looks like there is a new feature flag with Android Studio canary 5:

android.newDsl=false

when I set it to true, I got a crash I am using apollo 4.3.3

👋 I was looking at https://www.apollographql.com/docs/kotlin/advanced/nullability#migrate-from-nonnull and wanted to try the new nullability annotations. However, as it happens we're currently using the

responseBased

codegen, and I've got an error that

Apollo: responseBased codegen does not support @catch

. I'm not too familiar with the current nullability handling state, so just wanted to get some clarity on what to expect moving forward — I see there are some limitations to the

responseBased

codegen listed here, but nullability is not there

before I report an issue to Android studio, i wanted to see if there is anything that apollo kotlin IDE plugin is doing on sync of the project. Ive noticed nearly every time I sync in the IDE, a floating gradle daemon is kept alive and a new one is started next time i build, causing memory thrashing and slowdowns of gradle. Ive set arguments to code generation to a much lower memory number but the daemon seems to hog same size as my project gradle settings. I turned off automatic code generation while ide is running, but daemon still pops up. what made me think its an apollo bug, because I see logs (in 🧵 )