Hello! I am confused about something in the documentation, more specifically here:

By default, the GraphQL spec treats nullable variables as optional, so it's valid to omit them at runtime. In practice, however, this is rarely used and makes the operation's declaration verbose.

I am not sure that the "so it's valid to omit them at runtime" is actually true. Looking at the linked spec, if hasValue is is not true, and defaultValue doesn't exist, there's no value coercion happening. Which will lead to an error – that's exactly what we are experiencing with our Python server that uses Strawberry. Instead, what we are seeing is that we can omit the nullable variable only if there is a default value defined for it in the schema, which is not clear in Apollo's documentation. Am I making sense? 😄

Hi everyone. I have a little bit specific question about apollo's models(data classes) genereated from queries. In a multimodule android project, if we are using REST we'd create DTOs to represent network data and then use mappers to translate these network representations into models we can use in presentation layers. On the other hand when using apollo for android, those DTOs we'd create are already created (generated) by apollo actually. My question is when writing mappers to apollos generated models i feel like im coupling the network layer with data layer more than necessary because in case of graphql is gone than those mappers will be completely useless right ? Im trying to design a scalable codebase and dont want to couple anything more than necessary. Would you suggest creating my own DTOs as network data representations even though apollo creates those models behalf of me, for the sake of loose coupling in mappers ? Your help is much appreciated in advance. Thank you.

hey, i have a situation where we want to use mock data and construct them with mock values (custom scalars included) what we’ve had to do is do nasty workarounds like this:

override fun resolveLeaf(context: FakeResolverContext): Any {
        val mergedField = context.mergedField
        val type = mergedField.type.rawType()
        if (type is CustomScalarType) {
            // workaround the fact that Apollo doesn't have an API for constructing adapters
            // so we dont need explicit dependencies constructed here.
            val adapter = __CustomScalarAdapters.responseAdapterFor<Any>(type)
            if (adapter is AdapterResolver<*, *> && type.className == adapter.outputClass.qualifiedName) {
                @Suppress("UNCHECKED_CAST")
                return (adapter as AdapterResolver<Any, Any>).convert(resolver.resolve(context, adapter.inputClass))
            }
        }

        return super.resolveLeaf(context)
    }

since the default fake resolver does not handle scalar types. should I file a feature request?

Hi All, I have a problem understanding how using

@skip

/

@include

directives affect the normalized cache. The scenario is we have 2 operations

query

and

subscription

that use the same fragment, we want some fields to not be subscribed in the subscription as they never change, to do this we added the

@skip

directive on fields of the fragment. The issue is with Apollo v2 the fields that are skipped from a subscription, they are updated as

null

on the Apollo store normalized cache and overrides data fetched from the query. Apparently this issue does not happen with Apollo v3. Could you please help understanding what caused this issue/(feature) with Apollo v2 and what was fixed in Apollo v3.

Question regarding Optimistic Updates If the response from the mutation is a failure, due to no internet for example, but we've already written what we'd expect to get back into the cache using optimistUpdates, how should one fix the cache from that point? The UI would at that point show what we'd like the state to be like, but we will after the fact know that the mutation did not go through.

Using the test artifact with

registerTestResponse

etc. I have a test where I am testing a ViewModel, some action happens, some state is set to being in a "loading" state, so I want to be able to assert that, and then I want to be able to add the response to the ApolloClient, so that it will return that value back to the suspend function which is waiting for it, so that I can also assert what happens after the network has responded. What happens now instead is that I call the action on my ViweModel, the state is set to be in this pending state, then the suspend function tries to hit the ApolloClient, it does not find the response registered in the test

TestNetworkTransport

so it throws with

No response registered for operation ...

. Outside of Apollo, I typically make this work using Turbines, where if someone does an

awaitItem()

on it, it will not immediately throw, but it will wait a bit to see if someone will add a response to that turbine, and when it's there then it gives it to the caller who was waiting for it in a suspending manner. Does what I say here make sense? I can try to explain it a bit better if not 😊

Just got bit by a mistake in testing which I seem to be repeating quite often and I want to confirm that there is nothing better I can do here besides being more careful. We have two mutations in this shape:

memberUpdateEmail(input: MemberUpdateEmailInput!): MemberMutationOutput!
memberUpdateLanguage(input: MemberUpdateLanguageInput!): MemberMutationOutput!

notice the same response type on both of them. I was writing some tests, and I was enqueuing some responses like this:

apolloClient.registerSuspendingTestResponse(
 MemberUpdatePhoneNumberMutation(newPhoneNumber),
 MemberUpdatePhoneNumberMutation.Data {
  this.memberUpdatePhoneNumber = this.buildMemberMutationOutput { ... irrelevant what's in here }
 },
)
apolloClient.registerSuspendingTestResponse(
 MemberUpdateEmailMutation(newEmail),
 MemberUpdateEmailMutation.Data {
  this.memberUpdatePhoneNumber = this.buildMemberMutationOutput { ... }
 },
)

And I could not for the life of me figure out why my tests were failing but it was all here

MemberUpdateEmailMutation.Data {
 this.memberUpdatePhoneNumber = this.buildMemberMutationOutput { ... }
},

Which should have instead been

MemberUpdateEmailMutation.Data {
 this.memberUpdateEmail = this.buildMemberMutationOutput { ... }
},

Notice the difference in which field I am defining in the lambda there? And there was no type-safety related error kicking in here since they both happen to accept the same response type, so it was compiling just fine. Lmk if what I say is clear enough or not 🤗

If we use apollo and have caching enabled. Can we somehow do a full text search of the cached content?

👋 I'm seeing some

generateXxxApolloSources

tasks created during configuration time. It happens when calling

registerJavaGeneratingTask

, I think specifically in the

outputDir.get()

part — the

outputDir

is a provider based on

outputDir

argument of

DefaultDirectoryConnection

which in turn comes from

sourcesBaseTaskProvider.flatMap { }

. So in the end, the directory property is resolved which causes the task to be resolved/created, if I read that right? Or it's a misconfiguration on our end (because e.g. the variants shouldn't be resolved in the first place, or we may be doing something with Apollo tasks) or something else entirely?

Project that I work on we are currently hand crafting Data classes in our unit tests to provide GQL responses. I didn't know about this option generateDataBuilder before I explore using that option is there any plan to "officially" support it. Team doesn't like using "experimental" stuff hence the question;

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?