twilio / conversations-ios

SPM releases

Home Page:https://www.twilio.com/docs/conversations/ios/changelog

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

CancellationToken doesn't cancel sending a message if offline

StephenWilson opened this issue · comments

I have noticed a case where it is possible to attempt to send a message using the SDK and not be able to cancel sending.
This happens when an internet connection is not available. I found repeated attempts to send the message are made based off network errors to Twilio services showing in the logs.
After attempting to use the CancellationToken provided by the MessageBuilder buildAndSend function, it does not cancel sending the message unless a connection has already been made by the SDK to start sending the message.

I would expect that when the CancellationToken cancel function is called and:

  1. there is no active connection sending the message data
  • no further attempts to send the message are made
  • the MessageBuilders buildAndSend closure would fire to inform the caller that it has been cancelled
  1. there is an active connection sending message data
  • the current process to send the message is cancelled
  • the MessageBuilders buildAndSend closure would fire to inform the caller that it has been cancelled

What actually happens when the CancellationToken cancel function is called and there is no active connection sending the message data:

  • further attempts to make a connection are made on a regular basis until an internet connection is available and the message sends
  • no callbacks to the closure passed to MessageBuilder buildAndSend for the repeated failed attempts to send.

As a side note, I don't actually want the behaviour where the Twilio SDK make repeated attempts to send a message while offline. A more useful function for us would be to attempt to send a message and callback with an error if there is a lack of internet availability without silent attempts to retry.

Hello,

Thank you for pointing this out! We are working on a re-designed internal system of handling network states and most of the issues would be solved there. I will pay an additional attention to the behaviour of the cancellation token in the offline case, it should work just as you described.

Also there is a case when a request has been sent but answer didn't come yet, cancelling of the message send process will actually do virtually nothing. The SDK doesn't remove message if it was already sent, it just cancels the pending request.

There should be a new framework in place in 4.x versions, it's unfinished but perhaps it does what you want already?