esl / MongoosePush

MongoosePush is a simple Elixir RESTful service allowing to send push notification via FCM and/or APNS.
Apache License 2.0
108 stars 24 forks source link

Inconsistent behaviour sending data payload on apns vs. fcm #141

Closed ghard closed 6 months ago

ghard commented 4 years ago

It looks like the there's a discrepancy with how data payloads are handled between APNS abd FCM:

On 1.x using old FCM API I had no issues here. This behaviour is observed using the docker image mongooseim/mongoose-push:2.0.2

This is the JSON sent to mongoose-push:

PUSHER> (pusher.mongoose::make-message-json "fcm" "Hi" "This is it" :data "{\"Mmmmmm\": \"Bop!\"}")
"{\"service\":\"fcm\",\"topic\":\"com.example\",\"mode\":\"prod\",\"alert\":{\"title\":\"Hi\",\"body\":\"This is it\"},\"data\":{\"Mmmmmm\": \"Bop!\"}}"

And here's some of what I get back when sending this to 2 FCM and 2 APNS clients:

PUSHER> (pusher.mongoose::run-test *test-tokens* "Hi" "This is it" :data "{\"Mmmmmm\": \"Bop!\"}") ; test send to fcm and apns clients
(("fcm" 200 "null" "OK")
 ("fcm" 500 "{\"details\":\"UNREGISTERED\"}" "Internal Server Error")
 ("apns" 200 "null" "OK") 
 ("apns" 200 "null" "OK"))

This seems all fine: One of the FCM tokens is indeed expired.

(I do object to using a 500 reply here; probably 400, 404 or 410 would be more adherent to HTTP semantics as we're HTTP POSTing to a resource which doesn't exist. It certainly is not an "Internal server error", but I digress.)

How about something a bit more interesting?

PUSHER> (pusher.mongoose::make-message-json "fcm" "Hi" "This is it" :data "{\"foo\": {\"Mmmmmm\": \"Bop!\"}}")
"{\"service\":\"fcm\",\"topic\":\"com.example\",\"mode\":\"prod\",\"alert\":{\"title\":\"Hi\",\"body\":\"This is it\"},\"data\":{\"foo\": {\"Mmmmmm\": \"Bop!\"}}}"
(("fcm" 500 "{\"details\":\"invalid_notification\"}" "Internal Server Error")
 ("fcm" 500 "{\"details\":\"invalid_notification\"}" "Internal Server Error")
 ("apns" 200 "null" "OK") 
 ("apns" 200 "null" "OK"))

Wha-what?!

(Actually this time I think it MIGHT be the server's fault re. 500 reply, but not so sure.)

As seen on docker logs:

2020-03-11T14:42:35.791 [debug] pid=<0.7264.11> POST /v2/notification/<redacted>
2020-03-11T14:42:35.791 [debug] pid=<0.7264.11> worker=pools_warden, action=choose_pool, result=[:default], result_len=1
2020-03-11T14:42:35.792 [warn] pid=<0.7264.11>  Unable to complete push request due to service error: :invalid_notification in category: generic
2020-03-11T14:42:35.792 [debug] pid=<0.7264.11> Sent 500 in 553µs

Also sprach documentation on https://github.com/esl/MongoosePush:

"data (optional) - custom JSON structure sent to the target device. For APNS, all keys form this stucture are merged into highest level APS message (the one that holds 'aps' key), while for FCM the whole data json stucture is sent as FCM's data payload along with notification."

There seem to be no reservation there as per how complex or simple this json structure may be.

Maybe there is something else at play here? Failing deep-copy of the JSON structure perhaps?

rslota commented 4 years ago

@ghard ,

There are two separate "issues" I can see here:

  1. The UNREGISTERED error should not be HTTP 500 - I have no idea why this happens, as this was a bug that has been recently "fixed". Can you please let me know if you're sure that this is 2.0.2 releases? And if it indeed is, can you share more logs surrounding this HTTP 500 UNREGISTERED? It really should've been HTTP 410.

  2. Deep data payloads - according to FCM documentation (https://firebase.google.com/docs/reference/fcm/rest/v1/projects.messages#Notification), both keys and values in data have to be of type string. There is very little we can do about it apart from returning proper HTTP 400 code.

rslota commented 4 years ago

@ghard ,

Actually, the error codes you show very much suggest you're using v2 API. Can you confirm that? If so, just try to switch to v3, the only changes are in response error codes (v2 used 500 for almost anything).

ghard commented 4 years ago

cba7dc8b4e2c mongooseim/mongoose-push:2.0.2 "/opt/app/bin/mongoo…" 2 days ago Up 2 days 127.0.0.1:8443->8443/tcp mongoose-push

Re. v3 API: I would love to RTFM - however I don't Elixir and all examples and documentation ias n README.md refer to /v2 URLs only. I had no idea there even is such a thing as v3.

rslota commented 4 years ago

Indeed, even though documentation reflects v3 changes (error code list), examples still show v2 in URL's - will fix that.

ghard commented 4 years ago

Also:

$ curl http://localhost:8443/swagger.json
curl: (52) Empty reply from server
rslota commented 4 years ago

Swagger is disabled in prod right now, only available when compiling from source in dev environment. In 2.1 this will be configurable.

ghard commented 4 years ago

Maybe this could be exposed somewhere public, linked from the README.md?

ghard commented 4 years ago

Never hurts to have an authoritative source for an API document somewhere.

rslota commented 4 years ago

Yeah, that's true. I'll be pushing for external documentation anyway very soon, as README.md gets very crowded already - maybe Swagger (OpenAPI 3.0 after 2.1 release) could be part of that too.

ghard commented 4 years ago

Swagger is somewhat standardised, so it is a good formal way of defining the API. If it is already a build artefact, it could easily be added as an item in releases as well - as a file one could also extract from the docker image, or separately.

ghard commented 4 years ago

Okay. I am trying to send some test data to FCM - this is what my request JSON looks like:

"{\"service\":\"fcm\",\"topic\":\"com.example.app\",\"mode\":\"prod\",\"alert\":{\"title\":\"Hello\",\"body\":\"World oyster\"},\"data\":{\"event_data\":\"eyJtZWgiOiJib2luZyJ9\"}}"

I get an 200 reply and the alert gets shown on my 'droid. However the data payload is null.

This is what I see on the DEBUG log of MongoosePush - I'm having my worries about the notification as well as the data nodes being empty in what I suppose is being sent to FCM:

2020-03-17T11:09:41.172 [debug] pid=<0.1842.0> action=canceling_timer, request=%Sparrow.H2Worker.RequestState{body: "{\"message\":{\"android\":{\"data\":{\"event_data\":\"eyJtZWgiOiJib2luZyJ9\"},\"notification\":{\"body\":\"World oyster\",\"title\":\"Hello\"}},\"data\":{},\"notification\":{},\"token\":\"<redacted>\"}}", from: {#PID<0.28165.43>, #Reference<0.3784988276.708837377.52463>}, headers: [{"content-type", "application/json"}], path: "/v1/projects/myapp/messages:send", timeout: nil, timeout_reference: #Reference<0.3784988276.708837377.52470>}, result=4901

... stuff deleted ...

2020-03-17T11:09:41.173 [debug] pid=<0.28165.43> Sent 200 in 103ms

Am I still doing something wrong here? I've been successfully passing alerts with data payloads to our iOS clients with the v2 api for months so I guess I'm calling it correctly.

rslota commented 4 years ago

@ghard,

I am not sure what is the issue here. There is .message.android.data filled according to you request in the log that you provided. The .message.data is indeed empty, but according to FCMv1 docs, .message.android.data overrides .message.data when available (https://firebase.google.com/docs/reference/fcm/rest/v1/projects.messages#AndroidConfig).

pawlooss1 commented 6 months ago

Closing the issue due to lack of activity.