Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
ghard opened this issue Mar 11, 2020 · 13 comments
Closed

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

ghard opened this issue Mar 11, 2020 · 13 comments

Comments

@ghard
Copy link

ghard commented Mar 11, 2020

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
Copy link
Contributor

rslota commented Mar 12, 2020

@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
Copy link
Contributor

rslota commented Mar 12, 2020

@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
Copy link
Author

ghard commented Mar 12, 2020

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
Copy link
Contributor

rslota commented Mar 12, 2020

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

@ghard
Copy link
Author

ghard commented Mar 12, 2020

Also:

$ curl http://localhost:8443/swagger.json
curl: (52) Empty reply from server

@rslota
Copy link
Contributor

rslota commented Mar 12, 2020

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

@ghard
Copy link
Author

ghard commented Mar 12, 2020

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

@ghard
Copy link
Author

ghard commented Mar 12, 2020

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

@rslota
Copy link
Contributor

rslota commented Mar 12, 2020

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
Copy link
Author

ghard commented Mar 12, 2020

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
Copy link
Author

ghard commented Mar 17, 2020

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
Copy link
Contributor

rslota commented Apr 8, 2020

@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
Copy link
Member

Closing the issue due to lack of activity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants