[GH-ISSUE #208] Retry "Unconfirmed" Sent SMS (and/or more details in the log) #152

Closed
opened 2026-02-28 01:23:26 +03:00 by kerem · 6 comments
Owner

Originally created by @vorburger on GitHub (Oct 20, 2014).
Original GitHub issue: https://github.com/ushahidi/SMSSync/issues/208

I'm using SMS Sync with the "Get Reply from Server" and am returning "response JSON data from the Sync URL" as explained on http://smssync.ushahidi.com/developers/, but -so far- in Sent all outgoing messages appear stuck in "Unconfirmed" (green) state...

My phone was not on the mobile (not data/WiFi) network as I was inside a building when I've tried the very first one response - perhaps that's causing others behind it to remain stuck? Meanwhile I have tested sending an SMS to the same number use the native Android messaging, and that works (now), in an ideal world, the Sent view menu could have a Resend all Unconfirmed feature? And/or each individual message right-click "Retry" option (that's how Google Hangout SMS does it).

The Log only says "... Sending - [...] to [+91 ...]" - perhaps it could be a little more chatty if messages don't go out?

Originally created by @vorburger on GitHub (Oct 20, 2014). Original GitHub issue: https://github.com/ushahidi/SMSSync/issues/208 I'm using SMS Sync with the "Get Reply from Server" and am returning "response JSON data from the Sync URL" as explained on http://smssync.ushahidi.com/developers/, but -so far- in Sent all outgoing messages appear stuck in "Unconfirmed" (green) state... My phone was not on the mobile (not data/WiFi) network as I was inside a building when I've tried the very first one response - perhaps that's causing others behind it to remain stuck? Meanwhile I have tested sending an SMS to the same number use the native Android messaging, and that works (now), in an ideal world, the Sent view menu could have a Resend all Unconfirmed feature? And/or each individual message right-click "Retry" option (that's how Google Hangout SMS does it). The Log only says "... Sending - [...] to [+91 ...]" - perhaps it could be a little more chatty if messages don't go out?
kerem closed this issue 2026-02-28 01:23:27 +03:00
Author
Owner

@eyedol commented on GitHub (Oct 20, 2014):

@vorburger If it's in the sent view, then it means the SMS has been sent. The "Unconfirm" state means the OS didn't send back a confirmation state to SMSsync. So it's actually not sure if the message got to recipient or not. Usually the phone gets the confirmation state after a certain period.

Did the recipient receive the message?

<!-- gh-comment-id:59678134 --> @eyedol commented on GitHub (Oct 20, 2014): @vorburger If it's in the sent view, then it means the SMS has been sent. The "Unconfirm" state means the OS didn't send back a confirmation state to SMSsync. So it's actually not sure if the message got to recipient or not. Usually the phone gets the confirmation state after a certain period. Did the recipient receive the message?
Author
Owner

@vorburger commented on GitHub (Oct 20, 2014):

Thank you for your prompt responses(s)! I understand your explanation, but
unfortunately the recipient indeed did not receive the message.. I'm
testing this with two phones next to each other. Note that I CAN easily
successfully send a manual SMS from the phone running SMSSync to the other
phone, but NEVER get the response from SMSSync - so this does seem to be
some subtle bug, and not just a network delivery issue.

I just noticed that I got another one of those crashes I keep submitting..
This couldn't simply be the effect of that??

BTW Isn't it curious that the OS never correctly returns you the
confirmation state back? Because from Android Messages as well as Hangout
SMS support that works.. I can clearly see those going from Sending to
(Timestamp).

How can I help you to help me? (I probably could run custom build to try
something out, if that helps.)
On 20 Oct 2014 08:21, "Henry Addo" notifications@github.com wrote:

@vorburger https://github.com/vorburger If it's in the sent view, then
it means the SMS has been sent. The "Unconfirm" state means the OS didn't
send back a confirmation state to SMSsync. So it's actually not sure if the
message got to recipient or not. Usually the phone gets the confirmation
state after a certain period.

Did the recipient receive the message?


Reply to this email directly or view it on GitHub
https://github.com/ushahidi/SMSSync/issues/208#issuecomment-59678134.

<!-- gh-comment-id:59684790 --> @vorburger commented on GitHub (Oct 20, 2014): Thank you for your prompt responses(s)! I understand your explanation, but unfortunately the recipient indeed did not receive the message.. I'm testing this with two phones next to each other. Note that I CAN easily successfully send a manual SMS from the phone running SMSSync to the other phone, but NEVER get the response from SMSSync - so this does seem to be some subtle bug, and not just a network delivery issue. I just noticed that I got another one of those crashes I keep submitting.. This couldn't simply be the effect of that?? BTW Isn't it curious that the OS never correctly returns you the confirmation state back? Because from Android Messages as well as Hangout SMS support that works.. I can clearly see those going from Sending to (Timestamp). How can I help you to help me? (I probably could run custom build to try something out, if that helps.) On 20 Oct 2014 08:21, "Henry Addo" notifications@github.com wrote: > @vorburger https://github.com/vorburger If it's in the sent view, then > it means the SMS has been sent. The "Unconfirm" state means the OS didn't > send back a confirmation state to SMSsync. So it's actually not sure if the > message got to recipient or not. Usually the phone gets the confirmation > state after a certain period. > > Did the recipient receive the message? > > — > Reply to this email directly or view it on GitHub > https://github.com/ushahidi/SMSSync/issues/208#issuecomment-59678134.
Author
Owner

@eyedol commented on GitHub (Oct 20, 2014):

I checked the crash report you sent. Your issue is related to #163. I have it fixed. Will make an update this week. Thanks for reporting.

<!-- gh-comment-id:59687885 --> @eyedol commented on GitHub (Oct 20, 2014): I checked the crash report you sent. Your issue is related to #163. I have it fixed. Will make an update this week. Thanks for reporting.
Author
Owner

@vorburger commented on GitHub (Oct 20, 2014):

Aha. I'm currently in India, and would like to show someone a POC.. kinda
yesterday. I see that issue was fixed 5 months ago already.. So let me see
if I can myself build an APK from latest master, and revert back here.
(Unless you shout that's a bad idea for some reason.)

<!-- gh-comment-id:59688781 --> @vorburger commented on GitHub (Oct 20, 2014): Aha. I'm currently in India, and would like to show someone a POC.. kinda yesterday. I see that issue was fixed 5 months ago already.. So let me see if I can myself build an APK from latest master, and revert back here. (Unless you shout that's a bad idea for some reason.)
Author
Owner

@vorburger commented on GitHub (Oct 20, 2014):

That is unless you already have a Jenkins set up somewhere producing a
bleeding Edge APK nightly? Tx.

<!-- gh-comment-id:59688918 --> @vorburger commented on GitHub (Oct 20, 2014): That is unless you already have a Jenkins set up somewhere producing a bleeding Edge APK nightly? Tx.
Author
Owner

@eyedol commented on GitHub (Oct 20, 2014):

It's a new bug you've discovered similar to issue #163. I surely can send you a debug apk for testing.... I don't have Jenkins. shoot me an email at henry at ushahidi dot com

<!-- gh-comment-id:59688988 --> @eyedol commented on GitHub (Oct 20, 2014): It's a new bug you've discovered similar to issue #163. I surely can send you a debug apk for testing.... I don't have Jenkins. shoot me an email at henry at ushahidi dot com
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/SMSSync#152
No description provided.