Best way to determine specific errors?

[jstansbe]

I'm trying to determine when there is an invalid token, an expired token, message rate exceeded error, etc. (https://firebase.google.com/docs/cloud-messaging/send-message#admin_sdk_error_reference).

When i send a single message/notification to a token like so:
var response = await FirebaseMessaging.DefaultInstance.SendAsync(message);

I get the following response (I'm getting this when i catch a thrown exception from FirebaseMessaging... I think i must be using this incorrectly as this seems strange... shouldn't there be a response object?).

What am I doing that is incorrect? Shouldn't I be able to find a code that matches to whats in the admin_sdk_error_reference section? (link i have above)

Response status code does not indicate success: 400 (BadRequest)
{
  "error": {
    "code": 400,
    "message": "The registration token is not a valid FCM registration token",
    "errors": [
      {
        "message": "The registration token is not a valid FCM registration token",
        "domain": "global",
        "reason": "badRequest"
      }
    ],
    "status": "INVALID_ARGUMENT"
  }
}

[hiranya911]

Hi @jstansbe. You're not doing anything wrong. We don't expose any additional error details in the SDK at the moment. There's just a simple FirebaseException type that exposes a string, and this string may also include the full HTTP response text (which is what you're seeing).

There's a broader effort in progress to improve how errors are exposed in the SDK (it's being proposed across all of our SDKs). It's still at very early stages, and I don't have a concrete timeline for you. But when that effort lands, you will be able to easily check for error codes, and handle your errors accordingly.

The proposed API is something like:

class FirebaseException extends Exception {
  ErrorCode Code;
  String Message;
  HttpResponseMessage? HttpResponse; // System.Net.Http.HttpResponseMessage
  Exception InnerException;
}

class FirebaseMessagingException extends FirebaseException {
  MessagingErrorCode? MessagingErrorCode;
}

Unfortunately this means at the moment, you have to split and parse the exception message yourself to get any meaningful information out of it.

I should also point out that the FCM errors codes in the documentation are only really supported in our Node.js SDK. None of the other SDKs ever supported them, and they will most likely go away completely when the new error handling proposal is implemented (or they will get absorbed to the new MessagingErrorCode type mentioned above).

[swebgit]

Thanks for the info regarding this @hiranya911. I'm looking forward to being able to handle error codes from the Admin SDK more easily in .NET!

[KalleOlaviNiemitalo]

  HttpResponseMessage? HttpResponse; // System.Net.Http.HttpResponseMessage

Cool, my application can then get Retry-After from there, like the documentation of messaging/server-unavailable says it must do.

Unfortunately this means at the moment, you have to split and parse the exception message yourself to get any meaningful information out of it.

I think my application needs to search for the first newline, check that it is followed by "{", and parse JSON starting from there. I'd also like it to check that the HTTP response had Content-Type: application/json but it seems the library does not yet surface that information.

I should also point out that the FCM errors codes in the documentation are only really supported in our Node.js SDK.

I originally got the impression that those error codes would appear directly in the HTTP response. Can Google please clarify the documentation? I think keeping this issue open on GitHub may also help other users of the SDK figure the problem out faster.

[hiranya911]

Cool, my application can then get Retry-After from there, like the documentation of messaging/server-unavailable says it must do.

In the future the SDK will automatically handle retries. This is already implemented in our Java, Python and Go SDKs, and being currently implemented in Node.js (see firebase/firebase-admin-node#518). C# SDK will also have the same feature eventually.

I think my application needs to search for the first newline, check that it is followed by "{", and parse JSON starting from there. I'd also like it to check that the HTTP response had Content-Type: application/json but it seems the library does not yet surface that information.

You don't have to do any of that. System.Net.Http.HttpResponseMessage exposes the headers and content separately: https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpresponsemessage?view=netframework-4.8

I originally got the impression that those error codes would appear directly in the HTTP response.

The error codes currently in our documentation are not available on the actual HTTP responses. They are added by the SDKs. We are also working towards removing these SDK-specific error codes. Our new error handling regime will be aligned with https://cloud.google.com/apis/design/errors. These new errors codes will be present on the HTTP responses.

[KalleOlaviNiemitalo]

You don't have to do any of that.

I meant my application needs to search for a newline when it is still using FirebaseAdmin 1.4.0 or earlier.

Just ran into this issue as well. Having to parse JSON in an exception message is kind of ridiculous. The solution that @hiranya911 described sounds great, but I'm confused why at least the FirebaseMessagingException from the Java SDK hasn't been added in the meantime.

[hiranya911]

Here's the finalized design for the new exception types:

namespace FirebaseAdmin
  enum ErrorCode
    InvalidArgument
    FailedPrecondition
    OutOfRange
    Internal
    … other error codes 
  class FirebaseException : Exception
    ErrorCode ErrorCode { get; }
    System.Net.Http.HttpResponseMessage HttpResponse { get; }
    string Message { get; } // inherited
    Exception InnerException { get; }  // inherited

namespace FirebaseAdmin.Auth
  enum AuthErrorCode
    InvalidIdToken
    ExpiredIdToken
    TokenSignFailed
    CertificateFetchFailed
    UserNotFound
    DuplicateLocalId
    … other FirebaseAuth error codes
  class FirebaseAuthException : FirebaseException
    AuthErrorCode? AuthErrorCode

namespace FirebaseAdmin.Messaging
  enum MessagingErrorCode
    ThirdPartyAuthError
    Unregistered
    Internal
    InvalidArgument
    SenderIdMismatch
    Unavailable
    QuotaExceeded
  class FirebaseMessagingException : FirebaseException
    MessagingErrorCode? MessagingErrorCode

[swebgit]

@hiranya911 Will the new exception structures be included in the next release of the SDK?

[hiranya911]

@swebgit They will be released incrementally over a series of releases.

[hiranya911]

Note that the FCM APIs now support the fine-grained error handling scheme outlined above. FirebaseMessagingException and MessagingErrorCode types were included in the v1.8 release. More to come.

@hiranya911 So if we get a MessagingErrorCode.InvalidArgument, what is the recommended way to determine which argument was invalid? Is the only option still to parse the exception message as JSON?

[hiranya911]

A lot of the time, the error message indicates what went wrong.

FirebaseAdmin.Messaging.FirebaseMessagingException : The registration token is not a valid FCM registration token

This is directly extracted from the error response sent by FCM:

{
  "error": {
    "code": 400,
    "message": "The registration token is not a valid FCM registration token",
    "status": "INVALID_ARGUMENT",
    "details": [
      {
        "@type": "type.googleapis.com/google.firebase.fcm.v1.FcmError",
        "errorCode": "INVALID_ARGUMENT"
      },
      {
        "@type": "type.googleapis.com/google.rpc.BadRequest",
        "fieldViolations": [
          {
            "field": "message.token",
            "description": "The registration token is not a valid FCM registration token"
          }
        ]
      }
    ]
  }
}

If a certain INVALID_ARGUMENT error message doesn't have enough details, let us know by filing an issue (please provide enough details for us to repro the behavior), and we can work with the FCM team to get the necessary details included in the FCM server response.

Also note that we don't expect the clients to "handle" this sort of errors at runtime. INVALID_ARGUMENT errors are (usually) client errors and therefore should be "fixed" by the developers as opposed to "handling". A typical course of action at runtime would be to log the error message and other useful information, so the problem can be easily debugged and fixed.

In a future release (most likely the next release), clients will also have direct access to the HttpResponse object responsible for this type of errors, so they can dump all the relevant information (headers, payload etc).