875491 - thread UI gets broken when APN is bad

Status: RESOLVED DUPLICATE of bug 877064

(Firefox OS Graveyard :: Gaia::SMS, defect)

Description

[Dietrich Ayala (:dietrich)]

i had an AT&T APN that was fine for data but not for MMS.

this caused sent MMS to not get sent and stay forever in the thread with a spinner

and received mms to show the "you've received a message" message with a download button, but download button did nothing.

instead, we should:

* if possible, let the user know that the messages aren't being sent because bad APN settings

* handle the zombie sent/rec'd messages in a better way in the UI

Comment 1

[Corey Frang [:gnarf]]

I'm not sure what can be done here... Is the reason for an error even broadcast in a way we could interpret it?

Comment 2

[Corey Frang [:gnarf]]

The messages seem to get stuck in deliveryState[0] === 'pending' btw...

Comment 3

[Steve Chung [:steveck]]

It could be reproduced easily while switching the apn to custom settings. We need gecko to return error event if apn settings is invalid(for both sending/receiving). Maybe we need to set a timeout for this situation.

Comment 4

[:gerard-majax]

I'll try and see what I can do for this one.

Comment 5

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

After 3 times retry(interval is 5 minutes), the gecko will notify an error.

          aRequest.notifySendMessageFailed(Ci.nsIMobileMessageCallback.INTERNAL_ERROR);
          Services.obs.notifyObservers(aDomMessage, kSmsFailedObserverTopic, null);

Comment 6

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Looks like something wrong in the timer of retry send...
debuging..

Comment 7

[:gerard-majax]

No error seems to be sent also in case of MMSC triggering an error.

Comment 8

[Julien Wajsberg [:julienw]]

IMHO there are cases where we don't need to retry (like the MMSC proxy returning an error)

Comment 9

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Julien,
Thanks for your suggestion, we will skip retry in some case on following version but not v1.1.
There is no callback in current APN activate function. So we don't have a better way to do this. I think some cases like HTTP/503 is worth to retry. That is why we use retry mechanism.



(In reply to Julien Wajsberg [:julienw] (PTO 30th May -> 10th June with no access to my bugmail) from comment #8)
> IMHO there are cases where we don't need to retry (like the MMSC proxy
> returning an error)

Comment 10

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Dietrich, now 855610 877064 is landed. If APN wrong, gecko will retry(sending 3 times with 5 minutes interval and retry receiving 4 times with interval 1, 5, 10, and 30 minutes, Bug 840066).
After retry, the spin icon will turn to an error icon. Is this OK for you on this bug?

Comment 11

[Dietrich Ayala (:dietrich)]

Yes, I did see this now - eventually see an error icon with bad APN.

Comment 12

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

I close this bug because of we can see an error icon with bad APN when 877064 landed.