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

Implement send_each and send_multicast #692

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>
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

Successfully merging this pull request may close these issues.

2 participants