Hello! I have a question about watched queries, ma...

# apollo-kotlin

[Eduard Boloș]

Hello! I have a question about watched queries, maybe someone has an idea how to solve this conundrum I have. We are watching a query, but for each request that gets executed hitting the network, we need to update an HTTP trace header, with a new value for each call. Then when if the call fails and exception is thrown, we need to recoup the same header that was set for the call that failed, so we can report it to our observability platform. How would you do this? My intuition says that it would be something involving interceptors and ExecutionContext, but I didn't think it all through yet, so some pointers or examples would be very appreciated!
To make a rough sketch of what I want to achieve:

val traceId = Random.nextBytes(16).toHex()
val spanId = Random.nextULong()

val call = client.query(query)
    .fetchPolicy(FetchPolicy.CacheFirst)
    .refetchPolicy(FetchPolicy.NetworkOnly)
    .httpHeaders(listOf(HttpHeader("x-cloud-trace-context", "${traceId}/${spanId};o=1")))
    .watch(true, true)
    .catch { e ->
        maybeHandleCallException(e, traceId)
    }

but I want traceId to be different for each refetch, and in my catch I need the actual last value used.
To be honest, this is a bit of a made-up case, as the refetch policy we use is actually FetchPolicy.CacheOnly, to there's at most one single HTTP request being made, but I would still like to know how this would be done in case that we would change the refetch policy to the one in the code snippet above.

[bod]

Most probably an interceptor indeed but to be honest I'm not fully understanding the need 😅

Maybe you'll need to not use refetchPolicy and implement something yourself?

[Eduard Boloș]

Ah, yes, and I would have to throw my own kind of exception that contains the trace ID, I guess.
Well, this is pretty much hypothetical at the moment, but the idea was that if the watched query triggers more than one network call, each should have it's own distinct trace ID, so that if the result causes an error in the app due to a backend problem, we can correlate that with a request on the backend in our observability platform.

[bod]

ah I see 👍

I would have to throw my own kind of exception that contains the trace ID, I guess.

yeah something like that probably

[Eduard Boloș]

cool, I will keep this idea in mind then, if it comes down to it. thank you! and have a great weekend ahead!

[bod]

Thanks a lot! Don't hesitate to followup if you have something working or for any questions! Great week-end.