From the HTTP traffic below, we can see that the add-group-member and the listen have the same timestamp. This seems to indicate that the notification has remained queued on the server even though the cloud push was sent.
POST /push/add-group-member.icepush HTTP/1.1
Host: labs.icesoft.com
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Origin: http://seven.local:4000
Content-Length: 141
Connection: keep-alive
Accept: /
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 7_1 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11D5099e Safari/9537.53
Referer: http://seven.local:4000/cloud-push.html
Accept-Language: en-us
Accept-Encoding: gzip, deflate
ice.push.browser=3houk2oym&ice.push.apikey=197EBF31-40CD-444F-826F-10158A0F3581&group=f9c3601c-352f-4edf-a099-e904dd7d2f38&id=3houk2oym%3A2da
HTTP/1.1 200 OK
Date: Thu, 05 Dec 2013 22:17:44 GMT
Server: Apache-Coyote/1.1
Access-Control-Expose-Headers: ice.push.sequence,X-Connection,X-Connection-reason,X-Set-Window-Cookie,ice.push.heartbeatTimestamp,ice.push.heartbeat
Access-Control-Allow-Headers: origin, ice.push.sequence, ice.push.window, ice.push.browser, content-type, ice.parkids, ice.notifyBack, ice.push.heartbeatTimestamp
Access-Control-Allow-Origin: http://seven.local:4000
Access-Control-Allow-Credentials: true
Content-Type: text/plain; charset=UTF-8
Content-Length: 0
Connection: close
POST /push/listen.icepush HTTP/1.1
Host: labs.icesoft.com
ice.push.heartbeatTimestamp: 1386281832166
ice.notifyBack: apns:cb3053be6920d6c3e57101539df001fb0fffd89cc4af384d83be7d65328d86de
Accept: /
ice.push.browser: 3houk2oym
ice.push.sequence: 23
ice.parkids: true
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Origin: http://seven.local:4000
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 7_1 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11D5099e Safari/9537.53
ice.push.window: de4ee
Referer: http://seven.local:4000/cloud-push.html
Content-Length: 106
Connection: keep-alive
ice.push.browser=3houk2oym&ice.push.apikey=197EBF31-40CD-444F-826F-10158A0F3581&ice.pushid=3houk2oym%3A2da
HTTP/1.1 200 OK
Date: Thu, 05 Dec 2013 22:17:44 GMT
Server: Apache-Coyote/1.1
Access-Control-Expose-Headers: ice.push.sequence,X-Connection,X-Connection-reason,X-Set-Window-Cookie,ice.push.heartbeatTimestamp,ice.push.heartbeat
Access-Control-Allow-Headers: origin, ice.push.sequence, ice.push.window, ice.push.browser, content-type, ice.parkids, ice.notifyBack, ice.push.heartbeatTimestamp
Access-Control-Allow-Origin: http://seven.local:4000
Access-Control-Allow-Credentials: true
ice.push.heartbeat: 9711
ice.push.heartbeatTimestamp: 1386281864684
ice.push.sequence: 24
Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: must-revalidate
Pragma: no-cache
Expires: 0
Content-Type: text/xml;charset=UTF-8
Content-Length: 52
Connection: close
<notified-pushids>3houk2oym:2da</notified-pushids>
This was discovered using the BridgeIt Demo application deployed back in Nov/Dec of 2013. Since then NaaS (which is used by BridgeIt Demo) changed quite a bit. Using the "internal" Edge Push demo I was unable to reproduce this issue with the latest NaaS (which uses the latest ICEpush-EE). I checked the HTTP traffic that occurs after the Cloud Push notification is received and used to get back into the browser. I do see the add-group-member.icepush Request as expected but I don't see a listen.icepush Response containing <notified-pushids>. I tried multiple times.
Once we have BridgeIt Demo up-to-date again with the NaaS or once we see this issue again we should re-open this one.
Marking this one as Cannot Reproduce for now.