UnaryAsyncWrapper resume its continuation more than once

[remstos]

Hi,

We’re seeing quite a lot of random cases of the UnaryAsyncWrapper calling its continuation twice.
From our investigation, we could see that often it is happening when the request was actually cancelled and then its an error.
So something like this flow :

• request is triggered
• request is canceled
• request receives an error (either timeout or our own grpc errors)

UnaryAsyncWrapper.swift Line 52

Fatal error: SWIFT TASK CONTINUATION MISUSE: send () tried to resume its continuation more than once, returning ResponseMessage<Services_Call_Proto_V1_ListVoicesResponse>(code: Connect.Code.deadlineExceeded, headers: [:], result:
Swift.Result<TheMessagingApp.Services_Call_Proto_V1_ListVoicesResponse, Connect.ConnectError>.failure(Connect.ConnectError(code:
Connect.Code.deadlineExceeded, message: Optional ("timed out"), exception: nil, details: [], metadata: [:])), trailers: [:])!

Reproducibility

I was able to reproduce unconsistently, by

• reducing the timeout to 5s
• Have a network request sent and canceled quickly
• playing with the Network Link Conditioner to slow down network requests to make them fail

It is not consistent so I’m guessing there’s a race depending on how fast we’re cancelling the request.

I was trying to implement a fix, but I’m not sure what would be the best way to check that whether or not the cancelable closure has been canceled or not.

Thanks for any help here 🙏

[rebello95]

👋🏽 hi @remstos - thank you for flagging this issue! Can you share a bit more about how you're cancelling these requests? If you are able to put together an example (even if it inconsistently reproduces) within the Eliza example app in this repo, that would be super helpful as well.