Sandbox APNs servers return incorrect sequence number when rejecting some notifications
| Originator: | jon | ||
| Number: | rdar://19875314 | Date Originated: | 2015-02-18 |
| Status: | Duplicate of 19807791 | Resolved: | 2015-04-21 |
| Product: | Other | Product Version: | |
| Classification: | Other bug | Reproducible: | Always |
Summary:
When the APNs gateway rejects a notification because it does not include a token, the rejection message from the gateway does not include the sequence number of the rejected notification (i.e. the sequence number is always 0), even though the sequence number frame item was sent prior to the token frame item. This appears to be a new and very recent regression, and it only appears to affect the sandbox environment at this time.
Steps to Reproduce:
Send a push notification using the "Binary Notification Format." In the frame data, include a valid sequence number frame item ({itemId: 3, itemDataLength: 4, itemData: 0x12345678}) before a frame item that includes a zero-length token ({itemId: 1, itemDataLength: 0, itemData: null}).
Expected Results:
The APNs gateway should send an error-response packet that includes the sequence number of the previously-described notification ({command: 8, status: 2, identifier: 0x12345678}) and then close the connection.
Actual Results:
The APNs gateway actually sends an error-response packet that has a sequence number of zero regardless of the sequence number of the previous notification ({command: 8, status: 2, identifier: 0x00000000}) and then closes the connection.
Version:
Notes:
Please see https://github.com/relayrides/pushy/issues/149 for additional discussion. Some APNs provider libraries close connections by sending known-bad notifications to avoid a race condition where closing the connection from the provider side could result in the loss of an error-response packet for a notification rejected shortly before the connection was closed.
Configuration:
This only appears to occur in the sandbox environment at the time of this report; the production environment continues to function as expected.
Attachments:
Comments
Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!
Duplicate
Marked as a duplicate of 19807791 (closed).
Reply from Apple
Apple Developer Relations 21-Apr-2015 02:59 PM
Engineering has determined that your bug report is a duplicate of another issue and will be closed.
The open or closed status of the original bug report your issue was duplicated to appears in the yellow "Duplicate of XXXXXXXX" section of the bug reporter user interface. This section appears near the top of the right column's bug detail view just under the bug number, title, state, product and rank.
If you have any questions or concerns, please update your report directly here: http://bugreport.apple.com/.
Response to request for more information
With respect, I'm not sure if we're on the same page as to the nature of this issue. This isn't a crash happening on a phone; it's bad data coming back from the Apple-controlled push notification server. I'd be happy to provide whatever information you think might be helpful, but there are no logs or crash reports to be had in this case.
Are you asking for logs of push notifications arriving at the phone? The issue here is with notifications REJECTED by the APNs gateway, and as such, they never actually reach a phone. The problem is that when the gateway tells us WHICH notification was rejected, it sends the wrong notification ID in the case detailed in the original report.
Reply from Apple
Apple Developer Relations 04-Mar-2015 01:21 PM
Engineering has requested the following information in order to further investigate this issue:
~/Library/Logs/