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

Legacy API Deprecation for FCM #349

Open
euantorano opened this issue Jun 21, 2023 · 24 comments
Open

Legacy API Deprecation for FCM #349

euantorano opened this issue Jun 21, 2023 · 24 comments
Assignees

Comments

@euantorano
Copy link

euantorano commented Jun 21, 2023

We've received an email yesterday regarding deprecation of the legacy API for FCM. It links to an FAQ entry, which says to migrate usages of SendMulticastAsync to SendEachForMulticastAsync.

I see this method was added in commit 74bd9e5, but there has not been a release tagged since 24/03/2022.

Is there any chance a new release might be tagged and pushed to NuGet at some point soon (preferably before the API cutoff on 20/06/2024...)?

@google-oss-bot
Copy link

I found a few problems with this issue:

  • I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
  • This issue does not seem to follow the issue template. Make sure you provide all the required information.

@euantorano euantorano changed the title Legacy API Deprecation Legacy API Deprecation for FCM Jun 21, 2023
@euantorano
Copy link
Author

I note that this seems to affect every version of the Admin SDK, including:

In fact, the only version that seems OK is Node (functions implemented in firebase/firebase-admin-node@0da72ef and seemingly included in release 11.9.0)

@fu-mybeepr
Copy link

I was wondering the same. The FAQ page specifically says >= 2.4.0 for .Net, but apparently 2.4.0 is not released on either GitHub or Nuget.

@tonsnoei
Copy link

tonsnoei commented Jun 24, 2023

Additional to the above questions and important in relation to the performance of the library with this new (batch/multicast replacing) functionality:

I saw that in 2.4.0 the suggested usage of HTTP/2 for the HttpClient is not implemented yet. Right?

I am not sure how the HttpClient behaves. Does it automatically use HTTP/2 in some situations? From what I understand you have to set the handler of the HttpClient explicitly in the following way:

DefaultRequestVersion = new Version(2, 0); // Use HTTP/2

Just wondering...

Furthermore, keep up the good work!

@ewfian
Copy link

ewfian commented Jul 24, 2023

Additional to the above questions and important in relation to the performance of the library with this new (batch/multicast replacing) functionality:

I saw that in 2.4.0 the suggested usage of HTTP/2 for the HttpClient is not implemented yet. Right?

I am not sure how the HttpClient behaves. Does it automatically use HTTP/2 in some situations? From what I understand you have to set the handler of the HttpClient explicitly in the following way:

DefaultRequestVersion = new Version(2, 0); // Use HTTP/2

Just wondering...

Furthermore, keep up the good work!

Same question here.
From this doc, the default version is 1.1 on .NET 6

In .NET Core, the default message version differs based on the version you're using. .NET Core 2.1 changed the default value from 1.1 to 2.0. In .NET Core 3.0, the default value was reverted back to 1.1.
https://learn.microsoft.com/en-us/dotnet/api/system.net.http.httprequestmessage.version?view=net-6.0#property-value

FirebaseAdmin supports netstandard2.0, while netstandard2.0 compatible with .NET Core 2.1 and 2.2
https://github.com/firebase/firebase-admin-dotnet/blob/bc7bc090a0636b4c7487dd530511139ec60b167a/FirebaseAdmin/FirebaseAdmin/FirebaseAdmin.csproj#L5C30-L5C30
https://learn.microsoft.com/en-us/dotnet/standard/net-standard?tabs=net-standard-2-0

According this comment, the default behavior will vary between different .net versions

The HTTP message version. The default value is 1.1, unless you're targeting .NET Core 2.1 or 2.2. In that case, the default value is 2.0.

@euantorano
Copy link
Author

Now that 2.4.0 has been released, I've updated my project to it.

It looks like SendMulticastAsync hasn't been marked as obsolete/deprecated as the ObsoleteAttribute is commented out:

/// [Obsolete(Use <see cref="SendEachForMulticastAsync(MulticastMessage)"/> instead)]

It seems the attribute was added but commented out in 74bd9e5 - this is fairly easy to miss as Visual Studio by default continues the block comment when you enter a new line at the end.

@lahirumaramba
Copy link
Member

Hey folks, you are right there was a delay on the .NET release and the new batch send APIs are now available in v2.4.0
https://firebase.google.com/support/release-notes/admin/dotnet#version_240_-_12_july_2023

Thank you for flagging the issue with the Obsolete tag! @Doris-Ge could you take a look at the ObsoleteAttribute when you get a chance, please? Thanks!

@Doris-Ge
Copy link
Contributor

Thank you for flagging the issue with the Obsolete tag! @Doris-Ge could you take a look at the ObsoleteAttribute when you get a chance, please? Thanks!

Sure. I think I misunderstood the usage of Obsolete.

Thanks for flagging the issue! Will fix it.

@danports
Copy link

I upgraded a project to v2.4.0 and replaced usages of SendMulticastAsync with SendEachForMulticastAsync and had to revert the upgrade a few days later because SendEachForMulticastAsync did not deliver notifications to devices as reliably as SendMulticastAsync - some notifications seemed to be lost. Has anyone else that upgraded ran into this? I haven't yet dug into where in the stack the notifications were being lost, and it's possible it was a fluke.

@R4DIC4L
Copy link

R4DIC4L commented Aug 22, 2023

Is this related to the legacy Firebase Cloud Messaging (FCM) APIs which will be discontinued on June 20, 2024?

Does SendMulticastAsync use Batch send API?

On June 20, 2024, we’re reducing the number of Firebase Cloud Messaging (FCM) legacy register APIs and legacy send APIs that provide similar functionality. This step will allow us to provide you with a more consistent experience and align with Google security standards to improve security, reliability and performance.

Because of these API decommissions, some already-deprecated SDKs and features will stop working after June 20, 2024.

Please consult the tables below to find which Firebase Cloud Messaging (FCM) APIs and corresponding services/SDKs/features will be discontinued and replaced with new alternatives.

image

@R4DIC4L
Copy link

R4DIC4L commented Aug 22, 2023

I upgraded a project to v2.4.0 and replaced usages of SendMulticastAsync with SendEachForMulticastAsync and had to revert the upgrade a few days later because SendEachForMulticastAsync did not deliver notifications to devices as reliably as SendMulticastAsync - some notifications seemed to be lost. Has anyone else that upgraded ran into this? I haven't yet dug into where in the stack the notifications were being lost, and it's possible it was a fluke.

I am now performing the same upgrade to v2.4.0, but need more time to test the new SendEachForMulticastAsync method for notifications. Any particular use case when this happens? Is it happening for a high volume of notifications?

@Doris-Ge
Copy link
Contributor

Is this related to the legacy Firebase Cloud Messaging (FCM) APIs which will be discontinued on June 20, 2024?
Does SendMulticastAsync use Batch send API?

Yes and yes.

@hanselsen
Copy link

Hi all. Since this issue is still open, I wish to inquire about the status of it.
Reading back in this thread, it should be fixed when people upgrade to 2.4.0?

For example, I am using SendAllAsync and SendAsync. Do I need to do anything else?

@EricaLi123
Copy link

EricaLi123 commented Dec 15, 2023

Hi all. Since this issue is still open, I wish to inquire about the status of it. Reading back in this thread, it should be fixed when people upgrade to 2.4.0?

For example, I am using SendAllAsync and SendAsync. Do I need to do anything else?

You just need to upgrade to 2.4.0 and replace SendAllAsync with SendEachAsync.
https://firebase.google.com/support/release-notes/admin/dotnet#cloud-messaging

@alex-radch
Copy link

There are ~2 months left before the completion of firebase legacy methods, is there any news? Our company is waiting for a solution to this problem. Is there really only a manual way left for us, like presented above?

@tonsnoei
Copy link

There are ~2 months left before the completion of firebase legacy methods, is there any news? Our company is waiting for a solution to this problem. Is there really only a manual way left for us, like presented above?

As far as I know, just replace the SendAllAsync with SendEachAsync as @EricaLi123 mentioned. We did this with our company a few months ago. It works well.

@Igouist
Copy link

Igouist commented Apr 25, 2024

Is this related to the legacy Firebase Cloud Messaging (FCM) APIs which will be discontinued on June 20, 2024?這與將於 2024 年 6 月 20 日停用的舊版 Firebase Cloud Messaging (FCM) API 有關嗎?
Does SendMulticastAsync use Batch send API?SendMulticastAsync 是否使用批量發送 API?

Yes and yes. 是的,是的。

I just want to confirm that we are currently using SendMulticastAsync .

Should we switch to SendEachForMulticastAsync by June 20th, or am I misunderstanding something?

Thank you QQ

@tonsnoei
Copy link

Is this related to the legacy Firebase Cloud Messaging (FCM) APIs which will be discontinued on June 20, 2024?這與將於 2024 年 6 月 20 日停用的舊版 Firebase Cloud Messaging (FCM) API 有關嗎?
Does SendMulticastAsync use Batch send API?SendMulticastAsync 是否使用批量發送 API?

Yes and yes. 是的,是的。

I just want to confirm that we are currently using SendMulticastAsync .

Should we switch to SendEachForMulticastAsync by June 20th, or am I misunderstanding something?

Thank you QQ

Yes! Use SendEachForMulticastAsync now instead of SendMulticastAsync

@Sankarvjss78
Copy link

Step 1:

go to https://developers.google.com/oauthplayground/

1.Select the autorize api and after fill the input your own scopes (email, https://www.googleapis.com/auth/firebase.messaging) once it is complete after displayed the client id and client secret key for refresh_token.

Step 2:
POST => https://developers.google.com/oauthplayground/refreshAccessToken

{"token_uri":"https://oauth2.googleapis.com/token","refresh_token":"1//04BZzVDcaVl4vCgYIARAAGAQSNwF-L9IrPUzn_0****"} in body

Step 3:

POST =>> https://fcm.googleapis.com/v1/projects/chat-2dc2d/messages:send

headers: Bearer Y29**********.......

{
"message": {
"token": "*********",
"notification": {
"title": "Sample",
"body": "Sample"
}
}
} in body

@uchida-nunet
Copy link

Performance of the SendEachForMulticastAsync methods is too slow

After updating to v3.0.1, I am facing performance issues.

I am passing 500 tokens to the new SendEachForMulticastAsync for sending, but it takes several times (up to 20 times) longer compared to the old SendMulticastAsync.

Is there a way to resolve this? Also, from what I can see in this thread, it seems that sending via HTTP 2.0 may improve performance. Can this be applied to my project (.Net Framework 4.7.2)?

@nbevans
Copy link

nbevans commented Oct 1, 2024

Indeed, performance is diabolical with this new SendEachForMulticastAsync method

The HttpClient it uses is not configured to use HTTP 2.0. For .NET Framework, it needs to use the System.Net.Http.WinHttpHandler nuget which is what provides HTTP 2.0 support on NetFx.

@uchida-nunet
Copy link

@nbevans

Thank you for the information. I'll look into configuring the HttpClient with HTTP 2.0 support using the System.Net.Http.WinHttpHandler for .NET Framework as suggested. I appreciate your help!

@nbevans
Copy link

nbevans commented Oct 18, 2024

Unfortunately I don't think the HttpClient can be customised in these Google components. It's quite unfortunate as HttpClient, by its very design, is intended to allow you to customise it with custom handlers and message processors. But, unless I have missed something, this Google library has hidden it under layers upon layers of abstractions so you cannot even grab a reference to it, let alone customise it.

@uchida-nunet
Copy link

Thank you! I’ll try a few different approaches and see what works.

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

No branches or pull requests