Hey got some troubles using the apollo3.mockserver...

# apollo-kotlin

[Stylianos Gakis]

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

[Stylianos Gakis]

Is there any possible case where you can imagine such a test failing? Taking a data object, turning it into json with toJsonStringWithData and then passing it to the MockServer and querying for it should always result in this test passing as I see it. But things go bad, I’ll try to explain in a way that maybe helps you understand.

Trying to get where this happens through debugging, the stacktrace going upwards from the apolloClient.query(InsuranceQuery...).execute() skipping some.. then to execute inside HttpNetworkTransport then skipping some more, then this execute from OkHttpEngine (which calls RealCall from OkHttp) returns a body which when doing response.body!!.source().readUtf8() (consuming it I know, but when I run without the debugger I don’t do that and it still breaks) on it returns a json which is cut off 🤔 it ends with: ..."sections":[]}}],"activeContractBundles and that’s it, no " after that, the json ends abruptly. And that activeContractBundles is one of the two top-lever queries in the insurance query which returns a non-null list of non-null items, but should be able to be empty still.

Important to note that when looking inside CommonQueueMockServerhandler when trying to do handle and get the response from the queue inside there the whole json string exists intact.

Tried making a smaller object in case idk somehow the body was too long hence doing readUtf8 on it made it be cut off but no matter the length it gets cut the same way.

I don’t even know where to begin trying to understand how this goes bad tbh, if any of this makes any sense to you and you have some pointers I’d love to hear them.

The story behind why I am even doing this is because I want to see what I am doing wrong in how I am constructing the Data object myself from how the test builders do it. So far I’ve done this to see where to put the correct __typenames and it’s worked fine. But this time I am not even sure which part is failing.

[bod]

Interesting! Can I checkout the project to try locally?

[Stylianos Gakis]

Absolutely, feel free to reach out if anything doesn’t work, the tests should run by just checking out the codebase I think

[Stylianos Gakis]

Branch: apollo3-14-testing

[bod]

thanks! I'll have a look

[bod]

It looks like it's a MockServer issue! Still investigating loading

[Stylianos Gakis]

Hehe let’s squash them bugs, one at a time 🐞🔨

[bod]

well it was an encoding bug! You were impacted by it because you had accents in your payload 😅

[Stylianos Gakis]

Never would I have expected to have troubles with the Swedish language inside Android on top of in real life 😂 Thank you a lot! Next step, I’ll be writing my test cases in Greek letters to catch more bugs 🐞

[Stylianos Gakis]

On a slightly unrelated note, since the 3.3.1-SNAPSHOT is always the same name, but behind the scenes it point at different versions when there is a new snapshot, how do you usually tell gradle not to use the one cached locally?
I’ve been putting another version, syncing and changing again and syncing again but there must be another way.

[wasyl]

how do you usually tell gradle not to use the one cached locally?

I thought Gradle doesn’t cache snapshots by default but apparently it does for 24 hours. Some random advice on APIs used to adjust this: https://stackoverflow.com/a/42058780/1349855

Also you can point Gradle to a specific snapshot: https://medium.com/@vanniktech/pinning-a-snapshot-dependency-to-a-specific-version-b477f79469fc

[Stylianos Gakis]

Now that is a great solution, I always wondered this when I started using Snapsots for the first time with apollo. Pinning a specific snapshot version sounds like the most sensible way to go when I am going after specific fixes from the snapshots. Thank you a lot!

Also interesting that the ordering in this list is oldest to newest, I put the top one at first without looking at the date and was surprised it wasn’t what I wanted 😅 So weird imo. Aren’t people most often looking for the latest version instead of the oldest? 😄

[wasyl]

I think it’s sorted alphabetically 😄

The issue with pinning a snapshot version is that some repositories remove old snapshot versions after X time, and in those cases your build can start failing “randomly”

[Stylianos Gakis]

Scrolling to the bottom it is then 😅

Somehow, no idea how, changing to the specific version didn’t work by itself, but adding

testImplementation(libs.apollo.mockServer) {
    isChanging = true
}

and

resolutionStrategy.cacheChangingModulesFor(0, "seconds")

on top of that does work now.

Also my test now does in fact run locally with the fix in the latest snapshot. Yay 🥳