[REQUIRED] Step 2: Describe your environment
- Operating System version: MacOs 15.1.1 and docker from arm64v8/amazoncorretto:21-al2023-headless
- Firebase SDK version: 9.4.3
- Library version: firebase-admin-java
- Firebase Product: firebase-admin
[REQUIRED] Step 3: Describe the problem
TopicManagementResponse has currently 4 error codes:
private static final Map<String, String> ERROR_CODES = ImmutableMap.<String, String>builder()
.put("INVALID_ARGUMENT", "invalid-argument")
.put("NOT_FOUND", "registration-token-not-registered")
.put("INTERNAL", "internal-error")
.put("TOO_MANY_TOPICS", "too-many-topics")
Looking at https://developers.google.com/instance-id/reference/server , I see that it is currently also possible that RESOURCE_EXHAUSTED is returned. We log the response if there are any errors and currently see a lot of:
[Error{index=0, reason=unknown-error}]
This is not helpful, while it could be caused by RESOURCE_EXHAUSTED, which would be really good to know.
The second problem is that the error string comes from :
private Error(int index, String reason) {
this.index = index;
this.reason = ERROR_CODES.containsKey(reason)
? ERROR_CODES.get(reason) : UNKNOWN_ERROR;
If the reason is not in the predefined ERROR_CODES it would be more helpful to use the reason String that came in as an parameter than UNKNOWN_ERROR. UNKNOWN_ERROR could be used for null or empty Strings.
Steps to reproduce:
Cause a RESOURCE_EXHAUSTED and see that the error description is unknown-error
Solution
I went ahead and patched this for our own use. I will create a PR containing a commit that adds RESOURCE_EXHAUSTED and a commit that uses the parameter reason as fallback in case of a non empty string.
[REQUIRED] Step 2: Describe your environment
[REQUIRED] Step 3: Describe the problem
TopicManagementResponse has currently 4 error codes:
Looking at https://developers.google.com/instance-id/reference/server , I see that it is currently also possible that RESOURCE_EXHAUSTED is returned. We log the response if there are any errors and currently see a lot of:
[Error{index=0, reason=unknown-error}]
This is not helpful, while it could be caused by RESOURCE_EXHAUSTED, which would be really good to know.
The second problem is that the error string comes from :
If the reason is not in the predefined ERROR_CODES it would be more helpful to use the reason String that came in as an parameter than UNKNOWN_ERROR. UNKNOWN_ERROR could be used for null or empty Strings.
Steps to reproduce:
Cause a RESOURCE_EXHAUSTED and see that the error description is unknown-error
Solution
I went ahead and patched this for our own use. I will create a PR containing a commit that adds RESOURCE_EXHAUSTED and a commit that uses the parameter reason as fallback in case of a non empty string.