In the non-Txn Write, we should be catching the errors and wrapping them

[rhamzeh]

Checklist

• [X] I have looked into the README and have not found a suitable solution or answer.
• [X] I have looked into the documentation and have not found a suitable solution or answer.
• [X] I have searched the issues and have not found a suitable solution or answer.
• [X] I have upgraded to the latest version of OpenFGA and the issue still persists.
• [X] I have searched the Slack community and have not found a suitable solution or answer.
• [X] I agree to the terms within the OpenFGA Code of Conduct.

Description

In the non-txn Write, we should not error if a single tuple had a validation error

https://github.com/openfga/java-sdk/blob/b1e03e523c530824f5921313c2191dc5f6d93af8/src/main/java/dev/openfga/sdk/api/client/OpenFgaClient.java#L427C34-L427C99

Expectation

We should match what the other SDKs are doing, e.g.

• JS: https://github.com/openfga/js-sdk/blob/main/client.ts#L480-L491
• .NET: https://github.com/openfga/dotnet-sdk/blob/main/src/OpenFga.Sdk/Client/Client.cs#L232-L280

Catching the response if failed and setting status: ClientWriteStatus.FAILURE for the individual failed tuples

Reproduction

Have the following tuple already written

- user: user:81684243-9356-4421-8fbf-a4f8d36aa31b
  relation: viewer
  object: document:roadmap

and then do:

var request = new ClientWriteRequest()
    .writes(List.of(
        new ClientTupleKey()
            .user("user:81684243-9356-4421-8fbf-a4f8d36aa31b")
            .relation("viewer")
            ._object("document:roadmap"),
        new ClientTupleKey()
            .user("user:81684243-9356-4421-8fbf-a4f8d36aa31b")
            .relation("viewer")
            ._object("document:budget")
    ));
var options = new ClientWriteOptions()
    .disableTransactions(true)
    .transactionChunkSize(1); // Maximum number of requests to be sent in a transaction in a particular chunk

var response = fgaClient.write(request, options).get();

OpenFGA SDK version

v0.5.0

OpenFGA version

N/A

SDK Configuration

N/A

Logs

No response

References

No response

[sccalabr]

Id like to give this a try

[aaguiarz]

@sccalabr I'm assigning it to you, thanks!

[codeFather-x]

Hi @aaguiarz @rhamzeh ! I have started working on this. Here is a draft PR: https://github.com/openfga/java-sdk/pull/166

Would love to hear your thoughts on it, let me know if am in the right direction. I am curious to know if the headers I supplied are accurate, wasn't able to find references for erroneous headers.

I will work to have a parallel PR in the sdk-generator as well. Cheers!

After looking at other sdk files(python, dotnet), I believe the ClientWriteResponse model class for the java-sdk needs to be updated as it works for a single write transaction but is not extensible for multi-transactions(unlike other sdk's write response model class). I propose we model it the same way the other sdks have it.

Let me know if this makes sense and I will get started on the changes.

[codeFather-x]

While i am happy that this issue got resolved, its a little off putting that there was no response to the discussion comment i made earlier. Am new to contributing to open-source so am i missing something? Are we supposed to just send out PRs in the wild with no discussions? The silver lining is that my proposition was kind of right based on the merged PR. @rhamzeh @jimmyjames

[curfew-marathon]

Hi @codeFather-x on behalf of the OpenFGA team, I want to personally apologize for how this was handled. You have every right to be frustrated.

Your analysis was absolutely correct, and we're sorry we missed the opportunity to collaborate. We are using this internally to improve our process for reviewing contributions so this doesn't happen again.

We truly value your initiative and hope this experience doesn't discourage you from contributing in the future.

[codeFather-x]

Hi @curfew-marathon ! I appreciate your response. I am a fan of the OpenFGA project and use the java-sdk myself. Will definitely keep a lookout for other issues i can contribute to. Thanks for encouraging new contributors like me See ya in the next PR!