More detail when message Failed to be sent

I am using the REST API and for some reason (probably on my side) my iOS messages are not being delivered anymore. They are being set as “Failed”.

Is there a way to get more details on why it Failed?

Also, as you can see in the image below, the message Failed to be sent, but the status on the top of the above appears as “Delivered”

pushFailed.png

Hey Renato. Good timing, I just saw this error in our logs and fixed it.

The problem was that your message was too long by two characters. This length calculation includes the URL in your message. Our system was not correctly calculating the length when a custom URL was specified to return the correct error.

You should modify your message to be a little bit shorter, or use a URL shortener like bit.ly on the custom URL.

The “Delivered” status is technically correct. It just means that our system is done trying to send that message to all of the desired devices, whether they failed or not. With the new fix in place you’ll be shown an error message when the notification is too long before you get to the send page.

As a sidenote, this whole length issue will go away once iOS 8 is released. Apple will be doubling the max notification size even for devices not running iOS 8.

Thanks George for your quick reply (as always).

I was the one that let you know about the max chars problem and I fixed my length (by a trial-error approach) and it was working before. 

So, I think that you now are using a limit lower than it needs to be.

I will reduce my message anyway.

Thanks!

Yeah, there was a similar issue that you reported I think. This one actually cropped up due to an oversight I made when putting in the fix for the last one, and only affected messages with custom URLs.

Ok… the only problem is that I send the messages via REST API, so I will never go to the “send page” :slight_smile:

I think that you using the status as “Delivered” is confusing since in the bottom of the image you have the statistics and there the “Delivered” is equal to 0.  Maybe you wanna change one of these 2 names…

Ah, the Rest API will return an error with an error message explaining that the content was too long in that case.

Good point on reusing the word delivered in two different ways on that page. I’ll fix that now.

Hey Renato. Good timing, I just saw this error in our logs and fixed it.

The problem was that your message was too long by two characters. This length calculation includes the URL in your message. Our system was not correctly calculating the length when a custom URL was specified to return the correct error.

You should modify your message to be a little bit shorter, or use a URL shortener like bit.ly on the custom URL.

The “Delivered” status is technically correct. It just means that our system is done trying to send that message to all of the desired devices, whether they failed or not. With the new fix in place you’ll be shown an error message when the notification is too long before you get to the send page.

As a sidenote, this whole length issue will go away once iOS 8 is released. Apple will be doubling the max notification size even for devices not running iOS 8.

Thanks George for your quick reply (as always).

I was the one that let you know about the max chars problem and I fixed my length (by a trial-error approach) and it was working before. 

So, I think that you now are using a limit lower than it needs to be.

I will reduce my message anyway.

Thanks!

Yeah, there was a similar issue that you reported I think. This one actually cropped up due to an oversight I made when putting in the fix for the last one, and only affected messages with custom URLs.

Ok… the only problem is that I send the messages via REST API, so I will never go to the “send page” :slight_smile:

I think that you using the status as “Delivered” is confusing since in the bottom of the image you have the statistics and there the “Delivered” is equal to 0.  Maybe you wanna change one of these 2 names…

Ah, the Rest API will return an error with an error message explaining that the content was too long in that case.

Good point on reusing the word delivered in two different ways on that page. I’ll fix that now.