Hi, I am trying to perform a query with fetchPolicy but in version 3.2.1 the method does not exist, in the documentation it is but when I do it in an example the method does not exist, could you please help me Client

ApolloClient.Builder()
    .serverUrl(BuildConfig.HOST)
    .okHttpClient(okHttpClient.build())
    .autoPersistedQueries(
        httpMethodForHashedQueries = HttpMethod.Get,
        httpMethodForDocumentQueries = HttpMethod.Get,
    )
    .normalizedCache(cacheFactory)
    .addInterceptor(SessionInterceptor(context))
    .addInterceptor(LanguageInterceptor())
    .build()

Query

val queryResult = query(query).fetchPolicy(CacheFirst).execute()

Methods normalizedCache and fetchPolicy not found in 3.2.1

Hello everyone, I have a strange error

StandaloneCoroutine was canceled

it only happens to me when a specific api is consumed this is my apollo configuration

val logging = HttpLoggingInterceptor()
logging.level = HttpLoggingInterceptor.Level.NONE

if (BuildConfig.DEBUG) {
    logging.level = HttpLoggingInterceptor.Level.BODY
}

val okHttpClient = OkHttpClient.Builder()
    .addInterceptor(logging)
    .connectTimeout(8, TimeUnit.SECONDS)
    .readTimeout(8, TimeUnit.SECONDS)
    .writeTimeout(8, TimeUnit.SECONDS)

apolloClient = ApolloClient.Builder()
    .serverUrl(
        BuildConfig.HOST
    )
    .okHttpClient(
        okHttpClient.build()
    )
    .normalizedCache(
        SqlNormalizedCacheFactory(context, "h_apollo.db"),
        writeToCacheAsynchronously = true
    )
    .addInterceptor(
        SessionInterceptor(context)
    )
    .addInterceptor(
        LanguageInterceptor()
    )
    .build()

HttpLogginInterceptor print

<-- HTTP FAILED: java.io.IOException: Canceled

I have a build-convention plugin in kts where I depend on Apollo

implementation("com.apollographql.apollo3:apollo-gradle-plugin:3.2.2")

but I fail to use any type from Apollo plugin (ApolloExtension, etc.), no autocompletion, class is not "visible". Any idea why? I use convention plugin and configure other tools (like Detekt) and it works like a charm.

If not using subscriptions and instead either say polling or providing some kind of "pull to refresh" etc UI, what's best way of coordinating this when

watch

is being used to drive UI.....I think someone mentioned before that separately calling say

execute

on a query will cause cache to be updated and any UI observing the flow from

watch

will get the update?

In 2.x.x, we were using some custom thing for testing graphQL responses, which let us map mutations/queries to responses without having to specify what parameters would go into them. We did that by using the QUERY_DOCUMENT and mapping that to a response and then some code which I can’t quite get to migrate to 3.x.x. So I was thinking, maybe it’s time to use the new

MapTestNetworkTransport

instead. So I was wondering, since I don’t think there’s a way to do that right now, would it make sense to introduce a way to map an Operation to a result using something similar to registerTestResponse but by accepting an operation no matter what the inputs? Otherwise the annoying part is that I have to in cases like the one I linked above, go inside the Activity and check what is being passed inside those queries and copy it inside the tests. But in the tests that I am doing right now I am mostly interested in how the UI reacts to a particular response, not that I am also sending the correct query. With all that said, I know that the queue approach also exists, which doesn’t care for what the query was, but simply responds with specific things in order, but in many of these tests I do want the mapping functionality of at least the Operation type to the response, just not interested in what the input to that Operation was. Does my idea make sense? Does it sound reasonable? Would it even be feasible? Should I reconsider the approach I’m taking maybe? If you have any sort of input I’d love to hear it.

I am trying to upgrade from Apollo Android 2.5 to Apollo Kotlin 3.3, but the Gradle convert and codegen tasks are failing with a method not found:

void com.apollographql.relocated.vi.finallyStart(int)

how should I debug this? I don't see an un-relocated plugin or a mapping to at least track down what this is

Hi guys, I was trying out testing builders and I have to admit that I got burned a bit. This is what I have to have:

val data = UserDataQuery.Data {
  viewer = userViewer {
    userId = "userId"
    identity = identity {
      email = "<mailto:jon.snow@example.com|jon.snow@example.com>"
      name = name {
        first = "Jon"
        last = "Snow"
      }
    }
    preferredTrips = preferredTrips {
      edges = listOf(edge { node = node { kind = "MUSIC" } })
    }
  }
}

This was my first attempt:

val data = UserDataQuery.Data {
  userViewer {
    userId = "userId"
    identity {
      email = "<mailto:jon.snow@example.com|jon.snow@example.com>"
      name {
        first = "Jon"
        last = "Snow"
      }
    }
    preferredTrips {
      edge { node { kind = "MUSIC" } }
    }
  }
}

Have you considered something like this?

Hi! If I’m using

MemoryCacheFactory

&

SqlNormalizedCacheFactory

chained together, and

doNotStore(true)

is used on an Apollo (3.3.0) query with a

CacheOnly

fetch policy, would this prevent the memory cache being populated if only the SQL cache was read from?

👋 The Apollo Client Team is looking for product feedback from our community to help shape the future of our Clients. If you have some time and would like to contribute, please complete this survey by

June 17th, 2022.

It should take no longer then

10 minutes

and every response will be used to help us better understand your use of Apollo Client as well as what type of features and functionality you are looking for in the future. Thank you! 🙏

The survey is anonymous and the data will only used for directional product decisions, feature prioritization and the long term planning of our Client roadmaps.

If I haven’t configured a httpCache in my ApolloClient, does that mean that any calls to httpFetchPolicy on any of my `ApolloCall`s have no effect? I just realized we haven’t got that setup at all, so I am trying to understand how all these calls have been hehaving. Usually we paired them with editing the Apollo cache policy at the same time as well, so I guess we’ve only been relying on the apollo cache so far but we didn’t know it 😅. Which also bring the next question. How does it work if you’ve got both of them configured at the same time? Would most normal cases only need the apollo cache? Basically I am in unfamiliar grounds with this topic and I haven’t found anything in the docs regarding how to make the decision of what we should use, so any help would be appreciated!

The 3.0 migration doc mentions: “Watchers now default to a

CacheOnly

refetchPolicy instead

CACHE_FIRST

. To keep behavior unchanged, set a

refetchPolicy

on your watchers:” But the snippet directly under it shows

subscribe

instead of

watch()

. Is this wrong in the sense that it should be

.watch()

instead, or should the title of the section be

subscriptions

? I am kinda confused at that part of the document.

Hey got a potential bug, don’t have a nice reproducible build atm to show you, but I can ask it to see if from the top of your head you know that something changed in that part of the code, if not I can try and get something to show you. Using testBuilders, I get generated code that is red. Specifically on a generated file, a testBuilder on a enum turned into a sealed class. Got an enum like

enum CrossSellType {FOO \n BAR}

. Apollo {} is configured with

sealedClassesForEnumsMatching.set(listOf("CrossSellType", ...))

and then the generated code looks like this

"type" to resolve("type", CrossSellType.type.notNull(), knownValues().map { it.name }),

. Problem is, knownValues() returns a list of <CrossSellType> which is in fact a sealed class now, not an enum, so

.name

isn’t resolving, it’s red. On Apollo 3.3.0 rn, can’t really test earlier versions as a lot of other things will be red.

I am in a situation where I have

Operation.Data

and I would like to get their Json String representation. I have kind of by accident stumbled upon this function which is jvm only [1] and I think this almost is what I am looking for. However just had a question, there isn’t a

toJsonString

equivalent in there which is what I would like to get instead. And I can’t quite build my own version of it locally since I

adapter()

is private in that file and I don’t feel like copying that one into our project. I guess what I can do instead locally is imitate what the Adapter<D>.toJsonString is doing, with something like this right?

fun Operation.Data.toJsonString(
    scalarTypeAdapters: CustomScalarAdapters = CustomScalarAdapters.Empty,
    indent: String? = null,
): String {
    val buffer = Buffer()
    val jsonWriter = BufferedSinkJsonWriter(buffer, indent)
    toJson(jsonWriter, scalarTypeAdapters)
    return buffer.readUtf8()
}

But optimally, I’d like that function to be available to me from the library, where it can use the private

adapter()

function and not have to deal with buffers etc. in my local code. I am definitely not super confident with using them. So in short, do you think it’d fit to have a function with this body directly under this one, or should I just do the workaround I posted above (or something else if it is wrong of course)

fun Operation.Data.toJsonString(customScalarAdapters: CustomScalarAdapters = CustomScalarAdapters.Empty, indent: String? = null): String {
  return adapter().toJsonString(this, customScalarAdapters, indent)
}

Random question: [1] Is this due to the

getDeclaredField

calls etc? Is that using reflection only available on the JVM or something?

Posting a new thread about the use-case for the above post to keep it more organized 🧵

When using test builders, what’s the story about populating a field which is of a type that I have a custom type mapper for? Specifically, I am building an object that at some point has a java.time.LocalDate in there, and I am using the JavaLocalDateAdapter specified in my apollo {} configuration in gradle. In the test builder however it’s expecting a String, and I assume it will then try to use that Adapter to map it to the object. So should I have to do something like this on these cases: (For an object that has a field called “activeFrom”)

this.activeFrom = JavaLocalDateAdapter.toJsonString(
    LocalDate.of(2021, 4, 11), // I guess no need to pass anything for customScalarAdapters here
)

And then this line inside build should take are of it right?

"activeFrom" to resolve("activeFrom", LocalDate.type, emptyList()),

And a couple of thoughts if I assume that this is the way to do it. I’d of course optimally like to be able to just give it the object itself, but maybe this isn’t possible with the way the test builders are made. Maybe some convenience function could be generated that does this for us?

Possibly dumb question: Is there a way to share fragments between services? I have only one module but want to maintain "module like" behavior between folders in this module. For example I have

feature/home/GetHome.graphql

and

shared/CategoryFragment.graphql

. These files are each in it's own

service

so that I can specify a package name to the generated files. Now I want to access

CategoryFragment

from

GetHome

file but it errors out with `Cannot find fragment `Category``. Or maybe different question with the same outcome. Can I specify the package name of generated file more granularly so that the package names of different queries, mutations and fragments more resemble my defined project package structure?

A follow-up on the original workaround to using the LocalDate in a testBuilder here When I do

JavaLocalDateAdapter.toJsonString(LocalDate.of(2021, 4, 11))

I get back the string

""2021-04-11""

. Now if I do a test case like this:

val localDate = LocalDate.of(2021, 4, 11)
val jsonRepresentation = JavaLocalDateAdapter.toJsonString(localDate)
val buffer = Buffer().write(jsonRepresentation.encodeUtf8())
val jsonReader = BufferedSourceJsonReader(buffer)
val parsedAgain = JavaLocalDateAdapter.fromJson(jsonReader, CustomScalarAdapters.Empty)
assertThat(parsedAgain).isEqualTo(localDate)

It passes fine as expected. However when I am actually using it on the builder, it crashes at the adapter, since it tries to then parse

""2021-04-11""

directly, and LocalDate fails to do so. In this line in particular, the

nextString!!

returns the value with those double quotes and it fails. In the code snippet I put above, the encodeUtf8() part seems to turn it into a string with a single quote which makes this work, and maybe this isn’t happening in the test builders code? I am not quite sure what piece of the puzzle is going wrong, so I am posting this here in case you may have a better idea. Edit: For people who might read this at some future time and might be confused. I had simply misread that it was giving me back a String with double quoted strings, but it was just that in the debugger view in IntelliJ, to indicate a string it wraps it with quotations in the UI. The String I got back was in fact

"2021-04-11"

as expected and the workaround for the test builders was to strip the ‘“’ from the start and the end of the resulting string. This resulted in the String

2021-04-11

which was correctly parsed from the LocalDate.parse

Hey. There is information on multi module configuration for sharing schema. Is there any information about making a schema repo and using the same artifact in multiple projects? Is that not a recommended approach?

On the 22nd of March, you had a talk at Android Makers. I was looking for it to re-watch something but I realize it’s not on their YouTube channel. Is it available somewhere?

Another migration question (sorry 😅) Before we used to construct objects like this, for a query which looked like this where the return type of

status

is

ContractStatus!

which is a union with the three things you saw in the query among others. This worked fine somehow, since the __typename in the constructor put

val __typename: String = "ContractStatus"

and parsing it was no problem. In 3.x, we do not get that for free, and I need to go and put the correct __typename to each and every one of those constructors, and I am trying to avoid this if possible. I’ve put

__typename = ""

everywhere to make it compile, and it works for most cases, but not for one like here where even the test builder can’t automatically populate the __typename and I need to specify it myself, like here. So now due to this change, I would need to either adopt the testBuilders which handle this for me by forcing me to chose the typename when I need to, and even give me a comment above it with the possible correct options in the generated code (Nice work there, super convenient). Or I need to just go and hunt all the places where this problem happens and manually put in the correct __typename in all these places. Am I missing something in this migration story? I understand that the way we construct the Data objects in our tests might be a bit unorthodox, hence an easy solution may not exist, so just asking here for ideas 🤗

Hi everyone. I have a question: our scheme contains an enum with the

type

value. But apollo-kotlin generates the

type

field inside the companion object and inserts it in

knownValues()

. Is there a way to avoid/ignore it, cause the project doesn't compile in this case? Version - 3.3.0

Hey again. I have another issue:

HttpLoggingInterceptor

breaks the multipart request. If I don't add it, the request works. The exception is the same as here https://github.com/apollographql/apollo-kotlin/issues/2912, but I don't add 2 of them. I have my custom interceptor for authorization and logging. Any ideas?

About the multipart: we have this kind of mutation

mutation uploadFile($id: String!, $files: [Upload!]!)

The request is built like this

val upload = DefaultUpload.Builder()
            .content(file)
            .fileName(file.name)
            .build()

        val mutation = UploadFileMutation(id = recommendationId, files = listOf(upload))

But the backend tells me, that the received

files

field is not an array and returns an error to me. Are there any modifications for the multipart request if there's only 1 item to be sent?

Hey, while working with TestBuilders, the experience of the following could be improved a bit. When I am missing things that I haven’t specified, instead of getting a clear error of what it is that is missing, I get a random “__typename is not known at compile-time for this type. Please specify it explicitly” but this is in some seemingly random builder. Following the stacktrace I can see this comes from how the build() is specified, where there is the place where it says for example:

"variables" to resolve("variables", some type, emptyList(), { ctors here })

and the list of constructors is of all the possible things this could be. But some of those alternatives are builders that require the __typename to be specified, so it crashes when it tries to resolve them all. I then need to go back that stacktrace and find the last reference to my code to see which field it is that I need to define but isn’t there. Where this happens is places where there is a field which inside the generated builder has the type

List<Map<String, Any?>>

, so it’s not nullable and it needs to be specified. (The type inside the schema is [SomeType!]!. I am sure I’ve not explained this very well, but just wanted to type it out here for now and if it makes sense to you that’d be awesome, if not I will try to make a better explanation some other day 😅

Hey got some troubles using the apollo3.mockserver.MockServer for some tests.

Got a question about execute() on an ApolloCall. Before, there was one place where we did a simply fire and forget enqueue where I can see in the signature it only throws an exception when the call has already been executed, so we were pretty confident(right?) that one of the two callbacks would be called for sure. Now in 3.x we’ve changed it to execute() and then handle the same cases, but I was wondering, are we guaranteed for either of the two cases to be called now? For starters the coroutine could get cancelled inbetween so in that case I assume we won’t get any response, but even without cancellation, other things could go bad, like a parsing exception or whatever, and it would still not reach the

also

block right? In general I was thinking about this and I realize I can’t answer this question with much confidence, so I thought I’d ask here 😄

I have some queries that return a lot of nested fields. I have to access some of them by going through about 5 different other fields. Is there anyway to shorten how i’d access the brand in the generated kotlin code? I don’t want to do hero.friends.person.home.kitchen.stove.brand every time I need the brand.

{
  hero {
    friends {
      person {
          home {
            kitchen {
                stove {
                    brand
                }
            }  
          }
      }
    }
  }
}

Hey I was wondering if you have plans on when you’d like 3.3.1 to be merged back into main? Is there something particular that needs fixing before it is merged or something like that? We’re relying on some of the fixes that you helped me with recently (The swedish characters handling in the tests) that are on the Snapshot builds for now, and I’d simply like to know if there’s an ETA on the merge. We’re using the snapshot for now so that’s fine, I am not asking to rush you in any way, just to be better informed 🙌

In 2.x, we used to have subscriptionConnectionParams and subscriptionTransportFactory. In 3.x we don’t. I’ve tried constructing my ApolloClient without replacing it with anything, thinking maybe the necessary headers will be added from the OkHttp interceptor instead which didn’t work. The docs show a setup like this, but maybe this doesn’t work when there’s authentication etc on the play. Tried instead going full out by using subscriptionNetworkTransport on the builder but this also brings the same issue. I feel like I am missing some big part of the puzzle here somehow. The exception is all referencing methods that are internal to flow or the apollo library so they don’t give me a lot of ideas on where to look next 🤔 The message says:

com.apollographql.apollo3.exception.SubscriptionOperationException: Operation error ChatMessage

where ChatMessage is a subscription. And I don’t quite know where to go from there, hence here I am if you have any obvious thing I am missing.

Hi, we’re seeing cache-only queries on both Android & iOS being unexpectedly very slow, but I’m not really sure where to go with debugging / optimising performance. Hoping someone has some pointers – not sure if we’re running into an Apollo limitation or just missing something basic around Kotlin flows! (sorry for the large message 😅) On iPhone 13 Pro w/ latest iOS, I measured ~500-600ms to perform a cache-only query for our items (just via naive

print

statements before/after

query.execute()

) shortly after app launch. From inspecting the SQL DB, I’d guess this query reads ~2,000 SQL records worth of data. We’re using Apollo’s in-memory cache (10MB limit), chained with the SQL normalized disk cache, in a KMM app. Inspecting the cache seems easy on Android, from where I can see our disk cache DB file is ~1.1MB, with ~2150 records in total during an average flow through our app (launch app, query for account, query user’s paginated items). Each ‘item’ has ~15 immediate fields, most of which are nested fragments/objects. We’re creating a

flow { .. }

, and using

withContext(Dispatchers.Main) { .. }

inside this to execute the Apollo query for items and receive the response (we later perform some other operations within that flow, after emitting the queried cache-only items). Downstream shared view models collect via

IO

(Android)/`Default` Dispatcher (iOS), and further downstream, platform view models collect from shared view models on the main dispatcher/thread to present UI.