If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

MPN module - MismatchSenderId issue

Hello,

We are using lightstreamer, beside other things, to send android notifications using lightstreamer mpn module. It worked mostly with no problems, but now we started to get this exception when trying to send notification:

Internal exception caught while sending notification: GCM service error: MismatchSenderId
com.lightstreamer.h.k: GCM service error: MismatchSenderId
at com.lightstreamer.h.d.n.b(n.java)
at com.lightstreamer.h.d.n.b(n.java)
at com.lightstreamer.h.d.s.d(s.java)
at com.lightstreamer.l.c.aj.b(aj.java)
at com.lightstreamer.l.c.aj.run(aj.java)
at java.util.concurrent.ThreadPoolExecutor.runWorker( ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:617)
at com.lightstreamer.l.c.aw.d(aw.java)
at com.lightstreamer.l.c.ax.d(ax.java)
at com.lightstreamer.l.c.av.run(av.java)

We checked everything and senderID and server api key have correct values

We are using
Lightstreamer Server Allegro-Presto-Vivace version 6.1.0 build 1817
Android client 1.2

did you recently migrate your project from GCM to Firebase Cloud Messaging? If this is the case, the migration has probably changed your sender ID.

Since Server version 6.1 still uses GCM, you should ensure that you specify the sender ID you had before the migration. Using it everything should work correctly, at least until Google enforces the migration a year from now.

Sorry for delayed answer, but i tried to investigate this issue further. We have changed firebase account that we use, but we changed senderId and api key also. Can you explain me if this kind of issue can occur if mpn database tables got droped manually, because this is something that happened to us?

This kind of error can not related to the database. It is a backend service error. Dropping the tables, if performed when the Server is down, causes no harm (beside deleting devices and subscriptions, of course).

We are in the process of developing a new version of the MPN Module that uses Firebase as a backend service. During this process we encountered this MismatchSenderId error too, for our own demo project, after migrating it to Firebase. The only way to fix it was to use the previous sender ID on the app, the one we had before the migration (together with its previous API keys on the Server).

So far, our understanding of the Firebase migration process is that, once you migrate, the service console provides you with a new sender ID that is suitable for sending push notifications via Firebase Messaging only, not via GCM. I.e.:

An app using a sender ID provided by the GCM console obtains device tokens that are suitable for use with GCM backend service only.

An app using a sender ID provided by the Firebase console obtains device tokens that are suitable for use with Firebase Messaging backend service only.

In fact, we also encountered the opposite service error: Firebase Messaging refusing a push notification because the sender ID was still the one provided by the GCM console.

We will release the updated MPN Module soon, with it you will be able to use the new sender ID in your app. In the meantime, since the current MPN Module makes use of GCM, we are confident using your previous sender ID should fix the problem for you too.

Thank you for your detailed answer. When you talk about migration from GCM to Firebase, i am not sure that is case in our project. Because first project we created was through Firebase console, and then we switched to another, also created through Firebase. So i think there was no reason for migration at all. Also to note that this issue is not reproducible on all our test devices, just on some of them.

This changes the scenario completely. If you are experiencing the problem only on some devices, it may be due to how the device token is obtained. Let me explain.

As per Google’s suggested practices, if the package version of the app doesn’t change, our Android client library skips requesting a device token and reuses the last one it obtained (which is always saved on the SharedPreferences). So, the error may be due to some of your devices still using a token obtained with the previous sender ID.

If this is the case, uninstalling and reinstalling the app on those devices will force our client library to request a new token and should fix the problem.