-
Notifications
You must be signed in to change notification settings - Fork 338
Added minimal support for sending FCM messages in async using HTTP/2 #870
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
Conversation
error_dict, message = _parse_platform_error(content, status_code) | ||
exc = None | ||
if handle_func: | ||
exc = handle_func(error, message, error_dict) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As we discussed offline, let's confirm if this complex code path is necessary for error handling. If it is not, let's clean it up and keep it simple :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like we use this map FCM specific errors like:
FCM_ERROR_TYPES = {
'APNS_AUTH_ERROR': ThirdPartyAuthError,
'QUOTA_EXCEEDED': QuotaExceededError,
'SENDER_ID_MISMATCH': SenderIdMismatchError,
'THIRD_PARTY_AUTH_ERROR': ThirdPartyAuthError,
'UNREGISTERED': UnregisteredError,
}
We map to these errors by parsing the error response details. The default handle_func
(handle_X_error
) is agnostic to the source service of the error and doesn't try to parse based the error response details. FCM is the only service that currently makes use of this optional handle_func
but this seems like the correct way to support this scenario.
We could move the logic from the helper function _handle_func_X
to handle_platform_error_from_X
.
Will merge as is and we can revisit this in a follow up PR if necessary.
pyjwt[crypto] >= 2.5.0 | ||
httpx[http2] == 0.28.1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's add this new dependency to setup.py
…or FCM async and HTTP/2 support (#882) * Added minimal support for sending FCM messages in async using HTTP/2 (#870) * httpx async_send_each prototype * Clean up code and lint * fix: Add extra dependancy for http2 * fix: reset message batch limit to 500 * fix: Add new import to `setup.py` * Refactored retry config into `_retry.py` and added support for exponential backoff and `Retry-After` header (#871) * Refactored retry config to `_retry.py` and added support for backoff and Retry-After * Added unit tests for `_retry.py` * Updated unit tests for HTTPX request errors * Address review comments * Added `HttpxAsyncClient` wrapper for `httpx.AsyncClient` and support for `send_each_for_multicast_async()` (#878) * Refactored retry config to `_retry.py` and added support for backoff and Retry-After * Added unit tests for `_retry.py` * Updated unit tests for HTTPX request errors * Add HttpxAsyncClient to wrap httpx.AsyncClient * Added forced refresh to google auth credential flow and fixed lint * Added unit tests for `GoogleAuthCredentialFlow` and `HttpxAsyncClient` * Removed duplicate export * Added support for `send_each_for_multicast_async()` and updated doc string and type hints * Remove duplicate auth class * Cover auth request error case when `requests` request fails in HTTPX auth flow * Update test for `send_each_for_multicast_async()` * Address review comments * fix lint and some types * Address review comments and removed unused code * Update metric header test logic for `TestHttpxAsyncClient` * Add `send_each_for_multicast_async` to `__all__` * Apply suggestions from TW review
Adds basic logic for sending FCM messages in async using HTTP/2
This initial PR covers:
send_each_async()