Hello! Quick question about the

@optional

directive when used on a non-nullable object. In the generated model, the respective field becomes nullable, but in the

*Selections

object, the annotated field's type is still marked with

.notNull()

, making it a

CompiledNotNullType

. Is that on purpose? Context: we do some shenanigans in our

CacheResolver

to avoid some cache misses by returning null instead of nullable fields, and we were trying to do this for a field that is marked not null in the schema generated from the backend, so that we can successfully execute the query even if the user is offline (e.g. with

NetworkFirst

).

@bod do we have any target ETA for releasing the incubating cache back into production? You've made a lot of great changes that seem to be getting closer and closer to ready. I also noticed some work around migration which I assumed was part of the hold-up.

Hello! Not sure if its the right channel, but not sure also were to ask. I have a dummy polling system with apollo kotlin. Was just playing around today and I noticed the moment my screen turns of/gets blocked Im hit with

Failed to execute GraphQL http network request

(Underlying cause is unknown host exception) Is somethign expected from apollo? Or maybe someones knwo this is an android config thingy?

👋 hi! we have a significant number of Apollo internal errors happening constantly across all our apps and we're currently trying to understand why they're happening and what we can do about that — full original context is in this thread, but the summary is that writing to cache seems to fail consistently for some of our users and the main culprit seems to be `SQLiteBlobTooBigException`s we're currently planning to experiment with different cursor size to see if that helps, but we would also love to hear from you on a few different points: • can you think of anything else we could look into or investigate? • have you seen any other similar cases like this before where we could try to extract a learning or insight from? • would it be possible for the apolloExceptionHandler to expose more than just the exception thrown so we can maybe learn what are the queries causing the failure, or anything else that might help narrowing things down?

Hello! Do you have a recommendation for some static analysis tool that is able to detect if in a GQL query the

id

field is not included for objects that have such a field? Or do you think that this is something that could be part of the Apollo tooling? We are using

id

as the cache key in our

CacheKeyGenerator

implementation, and it would be useful to have such a check so that people's queries don't mess up the cache by mistake (we had several bugs and crashes due to this 😅)

hey not sure if related, but i did notice something strange. when I have continuous code generation on, there is a new gradle daemon process that keeps spinning up in the IDE. It is using the JBR bundled with the IDE, however our project uses a different java version 17 in the regular Java home location outside of the IDE. this results in at minium two daemons running while IDE is open. To eliminate the plugin as the culprit, where does it get the Java location from?

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?)