Mutate operation not cancelled under certain network conditions

[takuo3]

Hello,

First of all, I would like to express my gratitude for your work on this library. We have been using it in our project and it has been very helpful.

I am writing to discuss a behavior we observed while using the GraphQLClient.mutate function under certain network conditions. We simulated a 100% packet loss scenario using Network Link Conditioner and then executed a mutate operation. Before the operation timed out, we cancelled the associated cancellable. However, when we restored the network connection, it appeared that the operation continued to communicate and was not cancelled.

Interestingly, when we performed the same steps with the GraphQLClient.query function, the operation was successfully cancelled.

I would like to know if this is the expected behavior for the mutate function, or if there might be an issue with our implementation. Any guidance would be greatly appreciated.

Thank you for your time and for the great work you do on this library.

[maticzav]

Hello,

Thank you for your kind words!

Could you confirm that I understand the issue right?

The sequence of events that you expect to happen looks like this

1. start simulating 100% packet loss
2. start mutation
3. cancel mutation
4. stop simulating 100% packet loss
5. nothing

→ mutation is cancelled

but what actually happens is

1. start simulating 100% packet loss
2. start mutation
3. cancel mutation
4. stop simulating 100% packet loss
5. mutation is executed anyway

Is this correct?

---

This is a very interesting issue and I'd love to help since I can see that you also invested non-trivial amount of time into figuring it out. Ideally if you could record a Loom session or even create a reproduction example that would be invaluable to me.

What I need to check it out is

1. how you simulate 100% packet loss,
2. a working query scenario that you mention, and
3. a faulty mutation scenario that you mention.

Then, I'll check the code, check the spec and align the library as well as I can to work right.

Note that I don't know everything and I am eager to learn about all these edge cases, but there's a chance you know more about this topic and your contribution in any way would be at most welcome so that this library becomes even better 🙂

[takuo3]

Thank you for your response.

Everything is as you have written. Now, I will outline the steps of the test and its capture below.

Test Premise

I set up a local GraphQL server on MacBook A.
On MacBook B, I run mitmproxy, allowing the app on the simulator to access the server via the proxy and monitor the communication.
In this state, I use the Example of TheSocialNetwork to compare the behavior when cancelling feedQuery and postMutation.

Query Test

I set a breakpoint just before executing feedQuery, and when reached, I simulate 100% packet loss.
I tap the "Cancel refresh" button to cancel. "Client disconnected" is displayed on mitmproxy.
I stop simulating 100% packet loss.
I confirm that the response does not return and the operation is correctly cancelled.

https://vimeo.com/845186874?share=copy

Mutation Test

I post a test feed, set a breakpoint just before executing postMutation, and when reached, I simulate 100% packet loss.
I tap the "Cancel post" button to cancel.
I stop simulating 100% packet loss.
After a while, the response returns, suggesting that the operation could not be cancelled.

https://vimeo.com/845187256?share=copy

As a result, it seems that even if I cancel with cancelable in mutation, the request is sent.

Also, I provide the link to the repository I forked below:
main...takuo3:swift-graphql:feature/add_cancel_buttons

[shaps80]

@takuo3 since this is a few months old I'm locking the discussion for now. I'm currently cleaning up issues and discussions and I think ideally the above should be opened as an Issue if it's still a problem.

That being said, I'm only locking the discussion. Separately I'm also reviewing the concurrency implementation in general to ensure we can properly support async/await and perhaps resolve the above issue as well to ensure cancellations etc work as expected.

So this will be worked on whether you create an Issue or not, I didn't want you to think your issue above is being disregarded 👍