Skip to content

Implement send_each and send_multicast #692

New issue

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

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

Already on GitHub? # to your account

Merged
merged 1 commit into from
May 5, 2023

Conversation

Doris-Ge
Copy link
Contributor

send_each vs send_all

  1. send_each sends one HTTP request to V1 Send endpoint for each message in the list. send_all sends only one HTTP request to V1 Batch Send endpoint to send all messages in the array.
  2. send_each uses concurrent.futures.ThreadPoolExecutor to run and wait for all request calls to complete and construct a BatchResponse. An request call to V1 Send endpoint either completes with a success or throws an exception. So if an exception is thrown out, the exception will be caught in send_each and turned into a SendResponse with an exception. Therefore, unlike send_all, send_each does not always throw an exception for a total failure. It can also return a BatchResponse with only exceptions in it.

send_each_for_multicast calls send_each under the hood.

@Doris-Ge Doris-Ge force-pushed the dorisge/fcm-batch-send branch 5 times, most recently from 62560da to 284ec13 Compare March 31, 2023 18:39
`send_each` vs `send_all`
1. `send_each` sends one HTTP request to V1 Send endpoint for each message in the list. `send_all` sends only one HTTP request to V1 Batch Send endpoint to send all messages in the array.
2. `send_each` uses concurrent.futures.ThreadPoolExecutor to run and wait for all `request` calls to complete and construct a `BatchResponse`. An `request` call to V1 Send endpoint either completes with a success or throws an exception. So if an exception is thrown out, the exception will be caught in `send_each` and turned into a `SendResponse` with an exception. Therefore, unlike `send_all`, `send_each` does not always throw an exception for a total failure. It can also return a `BatchResponse` with only exceptions in it.

`send_each_for_multicast` calls `send_each` under the hood.
@Doris-Ge Doris-Ge force-pushed the dorisge/fcm-batch-send branch from 284ec13 to 52f30c2 Compare March 31, 2023 18:42
@Doris-Ge Doris-Ge requested a review from lahirumaramba March 31, 2023 18:47
@lahirumaramba
Copy link
Member

Thank you, Doris! Let's get the docs reviewed before merging

@Doris-Ge Doris-Ge merged commit 7f5d62e into fcm-batch-send May 5, 2023
@Doris-Ge
Copy link
Contributor Author

Doris-Ge commented May 5, 2023

I merged into fcm-batch-send branch. I'll ask for doc review for the PR being merged to the master branch.

Doris-Ge added a commit that referenced this pull request Jun 9, 2023
…h send (#706)

* Implement `send_each` and `send_each_for_multicast` (#692)

`send_each` vs `send_all`
1. `send_each` sends one HTTP request to V1 Send endpoint for each message in the list. `send_all` sends only one HTTP request to V1 Batch Send endpoint to send all messages in the array.
2. `send_each` uses concurrent.futures.ThreadPoolExecutor to run and wait for all `request` calls to complete and construct a `BatchResponse`. An `request` call to V1 Send endpoint either completes with a success or throws an exception. So if an exception is thrown out, the exception will be caught in `send_each` and turned into a `SendResponse` with an exception. Therefore, unlike `send_all`, `send_each` does not always throw an exception for a total failure. It can also return a `BatchResponse` with only exceptions in it.

`send_each_for_multicast` calls `send_each` under the hood.

* Add integration tests for send_each and send_each_for_multicast (#700)

* Add integration tests for send_each and send_each_for_multicast

Add test_send_each, test_send_each_500 and test_send_each_for_multicast

* chore: Fix pypy tests (#694)

* chore(auth): Update Auth API to `v2` (#691)

* `v2beta1` -> `v2`

* Reverting auto formatting changes

* undo auto formatting

* Add release notes to project URLs in PyPI (#679)

It's useful to be able to navigate to the release notes easily
from the package index when upgrading.

"Release Notes" is a special keyword that will have the scroll icon
in the project page.

A random example:

* https://pypi.org/project/streamlit/
* https://github.com/streamlit/streamlit/blob/815a3ea6fa3e7f9099b479e8365bd3a5874ddc35/lib/setup.py#L111

Co-authored-by: Lahiru Maramba <llahiru@gmail.com>

---------

Co-authored-by: Lahiru Maramba <llahiru@gmail.com>
Co-authored-by: pragatimodi <110490169+pragatimodi@users.noreply.github.com>
Co-authored-by: Samuel Dion-Girardeau <samueldg@users.noreply.github.com>

---------

Co-authored-by: Lahiru Maramba <llahiru@gmail.com>
Co-authored-by: pragatimodi <110490169+pragatimodi@users.noreply.github.com>
Co-authored-by: Samuel Dion-Girardeau <samueldg@users.noreply.github.com>
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants