App reports failed to send message when messages are indeed sent.

[Wyzzcow]

The app sometimes says

Not sent. Touch to try again.

So, I think that the message fails, I retry until it stops saying failed. Then, I leave the conversation and come back, and I see the message was sent multiple times.

It seems there is a problem with message send acknowledgement?

[michaelkourlas]

I've noticed this too. I think the problem is that VoIP.ms fails to acknowledge that the message was sent, but it actually is sent.

[michaelkourlas]

If I'm right, there's nothing the app can do to fix this issue.

[JohnMertz]

Some notes from my experience with writing a VoIP.ms IRC bot and some automation tools:

I can confirm that the return code is not always accurate (or non-existent). I put in a hack in my own code to mitigate this by performing a fetch prior to attempting to resend messages in my queue. If the message does actually come back in the fetch results, I just delete it from the queue. If the fetch operation fails, the queue run will also take a raincheck. This introduces more API calls, but you can at least limit the fetch range to start at the date of the oldest message in the queue.

This is an imperfect solution because it could be that there are multiple devices (each with their own cache) sending the same message. This could result in intentional duplicates being lost. Comparing attempted delivery time could help, but simultaneous duplicates could still be lost. The only other way for this to be prevented would be for the API to add a sending device ID system. This is less of a problem for personal SMS than automation tasks.

It is also possible that the falsely-failed messages may not necessarily show up immediately in the fetched results (I don't know whether this is the case or not). If true, it is still possible for subsequent attempts to create some duplicates.

VoIP.ms also somehow just creates duplicates on a regular basis. This applies to inbound and outbound SMS so it is not specifically related to the API. It is entirely possible that all previous attempts did actually fail, to the extent that no packets ever made it to their server, yet there will coincidentally be multiple copies of the message when it does succeed. Within this app it happens too frequently to be entirely coincidence, though.

This is an issue that has been around for a long time, although it seems it started getting worse in the last 6 months or so. It's not great overall, but I agree that these are issue that are much better to be addressed by VoIP.ms themselves. There may be some measures this app could take to mitigate the problem, but it cannot get to the root cause.

The only suggestion I might make for feature changes in the app regarding this issue is to clean up the conversation history. Specifically, log the number of times the message was attempted and visually compress the duplicate entries by the number of known attempts. An indicator could be added next to the remaining copy to make it clear that there were duplicates (eg. 'x4' next to a message that was both attempted and sent 4 times). This would only apply to outbound messages sent from that specific device (or a device that imported the relevant database). It would be purely aesthetic; it would not actually solve the fact that duplicates were sent. This is why I've never bothered to opened a request for such a feature and fully expect it to be ignored here. :)

[Wyzzcow]

Ah ok. Yea if it's an API issue with voip.ms i guess better to take it up with them. I've had an open ticket with them for months regarding duplicate inbound messages, i think this will never be solved... I figured that since some messages were properly sending without issue it might have been an app problem. Thanks for the app and feel free to close the issue. At least it was discussed 😉

…

On Tue, Sep 28, 2021, 16:46 John Mertz ***@***.***> wrote: Some notes from my experience with writing a VoIP.ms IRC bot and some automation tools: I can confirm that the return code is not always accurate (or non-existent). I put in a hack in my own code to mitigate this by performing a fetch prior to attempting to resend messages in my queue. If the message does actually come back in the fetch results, I just delete it from the queue. If the fetch operation fails, the queue run will also take a raincheck. This introduces more API calls, but you can at least limit the fetch range to start at the date of the oldest message in the queue. This is an imperfect solution because it could be that there are multiple devices (each with their own cache) sending the same message. This could result in intentional duplicates being lost. Comparing attempted delivery time could help, but simultaneous duplicates could still be lost. The only other way for this to be prevented would be for the API to add a sending device ID system. This is less of a problem for personal SMS than automation tasks. It is also possible that the falsely-failed messages may not necessarily show up immediately in the fetched results (I don't know whether this is the case or not). If true, it is still possible for subsequent attempts to create some duplicates. VoIP.ms also somehow just creates duplicates on a regular basis. This applies to inbound and outbound SMS so it is not specifically related to the API. It is entirely possible that all previous attempts did actually fail, to the extent that no packets ever made it to their server, yet there will coincidentally be multiple copies of the message when it does succeed. Within this app it happens too frequently to be entirely coincidence, though. This is an issue that has been around for a long time, although it seems it started getting worse in the last 6 months or so. It's not great overall, but I agree that these are issue that are much better to be addressed by VoIP.ms themselves. There may be some measures this app could take to mitigate the problem, but it cannot get to the root cause. The only suggestion I might make for feature changes in the app regarding this issue is to clean up the conversation history. Specifically, log the number of times the message was attempted and visually compress the duplicate entries by the number of known attempts. An indicator could be added next to the remaining copy to make it clear that there were duplicates (eg. 'x4' next to a message that was both attempted and sent 4 times). This would only apply to outbound messages sent from that specific device (or a device that imported the relevant database). It would be purely aesthetic; it would not actually solve the fact that duplicates were sent. This is why I've never bothered to opened a request for such a feature and fully expect it to be ignored here. :) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#236 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACEAVU6LQPCC3XXNAFDHNALUEISSFANCNFSM5E6DMHEA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.