Connection timeout when attempting push in prod mode

[ghard]

When running the latest official docker container

A simple check with curl:

curl --insecure --header "Content-Type: application/json" \
  --request POST \
  --data '{"service":"apns","mode":"prod","alert":{"title":"foo","body":"bar"}}' \
  https://localhost:8443/v2/notification/deadbeef

times out with no reply.
console output:

=INFO REPORT==== 10-Jul-2018::17:53:37 ===
    msg: "Starting reporters with []\n"
    options: []
17:53:37.011 [error] Supervisor 'Elixir.Logger.Supervisor' had child 'Elixir.Logger.ErrorHandler' started with 'Elixir.Logger.Watcher':start_link({error_logger,'Elixir.Logger.ErrorHandler',{false,false,500}}) at <0.1201.0> exit with reason normal in context child_terminated
17:53:37.024 [info] Application lager started on node 'mongoose_push@127.0.0.1'
17:53:37.025 [info] Application elixometer started on node 'mongoose_push@127.0.0.1'
17:53:37.025 [info] Application logger_lager_backend started on node 'mongoose_push@127.0.0.1'
17:53:37.025 [info] Application mime started on node 'mongoose_push@127.0.0.1'
17:53:37.025 [info] Application crypto started on node 'mongoose_push@127.0.0.1'
17:53:37.025 [info] Application plug started on node 'mongoose_push@127.0.0.1'
17:53:37.025 [info] Application asn1 started on node 'mongoose_push@127.0.0.1'
17:53:37.026 [info] Application public_key started on node 'mongoose_push@127.0.0.1'
17:53:37.026 [info] Application ssl started on node 'mongoose_push@127.0.0.1'
17:53:37.026 [info] Application ranch started on node 'mongoose_push@127.0.0.1'
17:53:37.026 [info] Application cowlib started on node 'mongoose_push@127.0.0.1'
17:53:37.027 [info] Application cowboy started on node 'mongoose_push@127.0.0.1'
17:53:37.027 [info] Starting Elixir.MongoosePush.Router with Cowboy on https://0.0.0.0:8443
17:53:37.066 [info] Starting FCM pool with API key *REDACTED*
17:53:37.067 [info] Using APNS certificate '/
*REDACTED*/Apple Development IOS Push Services: *REDACTED*' for 'dev' connection pool
17:53:37.068 [warning] Unable to extract APNS topic from the dev certificate due to: :no_extension
17:53:37.074 [info] Using APNS certificate '/
*REDACTED*/Apple Development IOS Push Services: *REDACTED*' for 'prod' connection pool
17:53:37.074 [warning] Unable to extract APNS topic from the prod certificate due to: :no_extension
17:53:38.021 [warning] lager_error_logger_h dropped 87 messages in the last second that exceeded the limit of 50 messages/sec
18:27:36.381 [info] Reconnecting to push service provider before request

The last message gets repeated each time I try it so I suspect that it's some sort of a connection error. It is not reported on the console though.

When using mode: dev we get a reply: {"details":"bad_device_token"} as expected.

( Are you sure changing the original 4XX reply from APNS to a 500 Internal Server Error, which would indicate that something is wrong with the push server and not the request is The Right Thing(TM) to do in the sense of following the HTTP and REST semantics? )

[ghard]

I attempted to gain some more info by setting PUSH_LOGLEVEL=debug but that didn't reveal much:
12:13:53.976 [debug] POST /v2/notification/deadbeef
12:13:53.977 [info] Reconnecting to push service provider before request
12:14:53.977 [warning] Unable to complete push request due to timeout
12:14:53.977 [debug] Sent 500 in 60001ms

Anyway the non-communication was caused by an invalid client certificate - I reckon APNS would've complained, but if it did, it wasn't handled by mongoosepush service.

[rslota]

Hi @ghard ,

I'm happy that you've managed to debug the issue.
We are currently rewriting the core of MongoosePush - the logs will be significantly improved and there will be more metrics. As for HTTP error status - I completely agree - we were planning to use 4XX codes, but we decided to wait till we have the refactored version. MongoosePush will use custom 4XX codes that will unify APNS and FCM errors. All of which will be properly documented.

[ghard]

Thanks for the info. Logging and error messaging, reporting configuration errors will help reduce initial frustration - especially for people who aren't well enough versed in Elixir to be able to debug the code. I'll be excited to take it out for a spin when done. Now I need to finish integrating this with our backend services.