The feedback/error callbacks are not working

[zepplock]

It seems like the feedback/error callbacks are not working properly. When I first connect I get this info:

[debug] [APNS] connected to gateway.sandbox.push.apple.com:2195
[debug] [APNS] connected to feedback.sandbox.push.apple.com:2196
[debug] [APNS] Feedback socket was closed. Reconnect in 10000s.

If I try to send something to a wrong id, Apple just closes the gateway.sandbox.push.apple.com connection and there's no error. Also next time callback connects - there's no feedback either.

What is the expected behavior?

[chvanikoff]

That is weird. The expected (and actual for me) behaviour is this: Can u provide any more relevant information?

[zepplock]

I just did

{:ok, conn}=APNS.start :dev
APNS.push conn, "0000000000000000000000000000000000000000000000", "test"

and received :ok, no other messages except

[debug] [APNS] Apple socket was closed
[debug] [APNS] connected to gateway.sandbox.push.apple.com:2195

Running on MacOS

elixir --version
Elixir 1.1.1

erl --version
Erlang/OTP 18 [erts-7.1] [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] [dtrace]

My config.exs:

config :apns,
  certfile: [
    dev: "config/apn_certs/ck-dev.pem",
    prod: "config/apn_certs/ck-prod.pem"
  ]

config :apns,
  callback_module:  APNS.Callback,
  keyfile:          [dev: "config/apn_certs/key-dev.pem", prod: "config/apn_certs/key-prod.pem"],
  cert_password:    nil,
  timeout:          30000,
  feedback_timeout: 1200,
  reconnect_after:  1000

[zepplock]

I think I know why. The size of the key matters! ;) If I do APNS.push pid, "0000000000000000000000000000000000000000000000000000000000000000", "Hello world!" I get an error back. But if I do APNS.push pid, "00", "Hello world!" I get nothing.

Of course this is not a library's fault since apn4ex has no way of knowing if token is valid or has a valid length.

Thanks for you help and a great library!

[chvanikoff]

Yeah this makes sense. APNS receives incorrect packet in that case and closes the connection.

[zepplock]

I think it would be better to call error callback in this case as well. As a developer working with a library I want to have one callback to handle a case where the token was wrong. Token is the only thing that I don't control since it comes to me from a device. What do you think?

[chvanikoff]

ok, I think I'll do this

[zepplock]

Thanks!

[chvanikoff]

Done. Also I've added error callback trigger on payload size error. Changelog

[zepplock]

Thanks, will test today.

[zepplock]

Tested 0.0.6 - :+1:

[kroucis]

I still can't get the feedback callbacks to work at all (v 0.0.6). Below is my configuration:

config :apns,
  certfile:         "MyCertAndKey.pem",
  callback_module:  APNS.Callback,
  timeout:          30000,
  feedback_timeout: 1200,
  reconnect_after:  1000

[chvanikoff]

@kroucis hi, can u share logs? Maybe even complete code? As of now circumstances when it fails for you are not obvious.

[kroucis]

Here is the call to APNS

{:ok, pid} = APNS.start :dev
allTokens = Repo.all from pt in PushToken, select: pt.token
for token <- allTokens do
  APNS.push pid, token, "Hello!"
end
# I would call APNS.stop(id) here, but that kills the process before it can actually send anything to Apple.

Is it possible that calling APNS.start/1 and then sending notifications is somehow not giving the service enough time to start up the feedback connection? Here are the logs for that code:

[debug] [APNS] connected to gateway.sandbox.push.apple.com:2195
[debug] [APNS] connected to feedback.sandbox.push.apple.com:2196
[debug] [APNS] Feedback socket was closed. Reconnect in 1200000s.

As a note: notifications appear to be working correctly.

[chvanikoff]

Is it possible that calling APNS.start/1 and then sending notifications is somehow not giving the service enough time to start up the feedback connection? no it shouldn't be the case But I want to ensure you are clear on feedback purpose: The Apple Push Notification service includes a feedback service to give you information about failed remote notifications. When a remote notification cannot be delivered because the intended app does not exist on the device, the feedback service adds that device’s token to its list. Remote notifications that expire before being delivered are not considered a failed delivery and don’t impact the feedback service. By using this information to stop sending remote notifications that will fail to be delivered, you reduce unnecessary message overhead and improve overall system performance.

Are you sure feedback should be received? Can you also test with any wrong token and confirm error callback is properly triggered?

[kroucis]

Ah! Fair enough. I was mistaken on the intent of the feedback system. When attempting with an invalid token, I get the following in red:

[error] [APNS] Error "Invalid token size" for message <<142, 231, 22, 86>>

This seems to be in line with what you are saying. Sorry for the false alarm.