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

hey, i noticed a nuance that im sure many do not run into. For reasons at my company, we've used a node cli tool to do registration using our own custom rules, and introspection functionality. What i noticed is that the tool uses the

graphql

node package to run introspection. The introspection result is quite a bit smaller than the kotlin one (75K lines vs 100K in kotlin) due to the comments on every type and field being multiline in kotlin vs single line in node. we're migrating to native apollo kotlin introspection using gradle. kotlin:

"""
  The globally unique identifier.
  """
  id: ID!

Node:

"""The globally unique identifier."""
id: ID!

is this expected? any way to direct the apollo kotlin introspection to do the same?e

While doing some changes today, we accidentally wrote this piece of code:

...
.fetchPolicy(FetchPolicy.CacheAndNetwork)
.execute()

And we were hit with the

com.apollographql.apollo.exception.DefaultApolloException: The operation returned multiple items, use .toFlow() instead of .execute()

exception. Now the question is, is there something we can do regarding avoiding this, besides either being careful to just not write this or working on some intricate linting tool which might be able to catch it? In past years I don't recall seeing this before so admittedly it is not a common scenario 😄

Is there an example of a

ExecutableDocumentTransform

that would add `id`s to selections on types that have

id

field in the schema, but it's not in the current selection set? I saw https://github.com/apollographql/apollo-kotlin/blob/415255a8d4203b2714924584a4e80f2283274769/tests/compiler-plugins/add-field/src/main/kotlin/hooks/TestPlugin.kt#L44 and it got me somewhere, but I'm struggling to get and pass around the type I'm currently processing (so that I can look up in schema whether it has an

id

field defined)

While updating from alpha 6 to alpha 7 of the new normalized cache (with Apollo 4.3.3), following the release notes guidance, I'm seeing the compiler error

Apollo: unknown foreign schema 'cache/v0.3'

for the following at the top of my updated

graphqls

file:

extend schema
@link(url: "<https://specs.apollo.dev/kotlin_labs/v0.5>", import: ["BuiltIn", "@mapTo"])
@link(url: "<https://specs.apollo.dev/cache/v0.3>", import: ["@connection", "@typePolicy"])

Does this require an Apollo 5.0 alpha, or is there something else going on here?

hey, working on a custom client directive i want to adjust codegen + operations output based on the applied directive. I plan on using a compiler plugin w/

registerForeignSchemas

to define a custom directive. Is this the right approach? or do i also need to define it in my repos

extra.graphqls

file?