[FR] Improve exception handling for rate limiting

[skion]

Is your feature request related to a problem? Please describe.

When using the SDK to create email action links, such as for password reset or email verifications, Firebase is strongly rate limiting for good reason. However, it is currently impossible to (programmatically) detect whether the reason for failure was indeed rate limiting, or something else, since in both cases a generic InvalidArgumentError exception is raised.

Describe the solution you'd like

A way to distinguish rate limiting from other client or server side errors, so that my API is able to return 429 or 503 responses with a Retry-After header instead of a generic 500 response in those cases.

Describe alternatives you've considered

In order to prevent my API from returning generic 500 I'm considering to implement my own rate limiting in front now. However, that is less elegant since I would need to heuristically match Firebase's rate limiting algorithm in order to prevent emitting 500's anyway.

Additional context

Currently the RESET_PASSWORD_EXCEED_LIMIT error code from Firebase is swallowed and converted into a INVALID_ARGUMENT code, because this type of exception is not special-cased:

InvalidArgumentError('Error while calling Auth service (RESET_PASSWORD_EXCEED_LIMIT).')

Note that the same holds for building email verification links:

InvalidArgumentError('Error while calling Auth service (TOO_MANY_ATTEMPTS_TRY_LATER).')

In both cases the original code is not introspectable in the exception, except by parsing the error string.

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[mohitCodepy]

@lahirumaramba , Is anyone actively working on this issue ? If not then please assign me, thanks

[skion]

@lahirumaramba @pragatimodi FWIW I linked a PR a while ago that I believe solves this problem. Can someone have a look at it?