Closed ghard closed 6 months ago
@ghard ,
There are two separate "issues" I can see here:
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.
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.
@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).
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.
Indeed, even though documentation reflects v3
changes (error code list), examples still show v2
in URL's - will fix that.
Also:
$ curl http://localhost:8443/swagger.json
curl: (52) Empty reply from server
Swagger is disabled in prod
right now, only available when compiling from source in dev
environment. In 2.1
this will be configurable.
Maybe this could be exposed somewhere public, linked from the README.md?
Never hurts to have an authoritative source for an API document somewhere.
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.
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.
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.
@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).
Closing the issue due to lack of activity.
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:
And here's some of what I get back when sending this to 2 FCM and 2 APNS clients:
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?
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:
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?