Feature Request: Exception Handling for OpenFGA Client Errors (e.g., TupleAlreadyExistsException)

[ankit-sapkota]

Overview

When working with the OpenFGA client, errors such as ExecutionException with FgaApiValidationError as the cause make it difficult to pinpoint specific issues. For example, writing a tuple that already exists throws a generic error, requiring manual parsing of the underlying message to identify the cause.

Problem

Currently, developers must manually parse the error message to determine the specific cause, like a duplicate tuple. This approach adds complexity and can lead to mistakes when handling multiple error types.

Proposed Solution

Introduce custom exceptions (e.g., TupleAlreadyExistsException, InvalidTupleFormatException) that allow developers to handle specific errors directly without parsing error messages.

Benefits

• Simplifies error handling by catching specific exceptions.
• Improves code readability and maintainability.
• Reduces the risk of incorrect error handling due to manual parsing.

Current Workaround

FgaApiValidationError error = (FgaApiValidationError) e.getCause();
String responseData = error.getResponseData();

ObjectMapper objectMapper = new ObjectMapper();
Map<String, Object> responseMap = null;
try {
    responseMap = objectMapper.readValue(responseData, new TypeReference<>() {});
} catch (JsonProcessingException ex) {
    throw new CustomException("Failed to parse response from openfga");
}

String message = (String) responseMap.get("message");
if (message.startsWith("cannot write a tuple which already exists:")) return;

Improved Solution

With custom exceptions like TupleAlreadyExistsException, the error handling could be simplified:

try {
    // Write tuple
} catch (ExecutionException e) {
    TupleAlreadyExistsException cause =e.getCause();
}

[rhamzeh]

At the moment the SDKs cannot surface new error types without relying on parsing the API messages themselves, which would mean the SDKs are now dependent on the API error messages.

This needs to be fixed at the API level to return consistent error codes - which the SDKs can use.

The best the SDKs can do without being themselves dependent on parsing the messages is surface those API error messages in a better way for the end-user. (e.g. when serializing to a string, append more data like in https://github.com/openfga/spring-boot-starter/pull/90/files#diff-3463c57f6d008d8e0ad35501bef1bbd8dcc21c24b14ff005afba0f65c872213cR70-R84)

cc @dyeam0