Is it possible to disable write/delete error checking?

[Valkryst]

I'm currently integrating a client's application with OpenFGA and it's Java library, and I've run into a problem while handling transactional, batched insertions and deletions in both OpenFGA and the client's DB in tandem.

In this situation, there is a set of creation and deletion events for group memberships and group-parent relationships. There are users which are members of a group as well as groups which can have a parent group, and each event describes the creation or deletion of one of these relationships.

For changes to the client's DB, I'm using a transaction which can be rolled-back in the event of some failure in the code. For OpenFGA, I'm creating a ClientWriteRequest and applying equivalent (to the Postgres transaction's inserts/deletes) write and delete calls. I'm also running the OpenFGA transactional call first, and rolling-back the DB changes if it fails.

The problem arises when I run the OpenFGA transaction. i.e. When I write the ClientWriteRequest to OpenFGA's API.

There are cases where a delete event will exist with no corresponding creation event or existing relationship in OpenFGA. In this case, I'm telling OpenFGA to delete something which does not exist, so the transaction fails and OpenFGA returns something along the lines of {"code":"write_failed_due_to_invalid_input","message":"cannot delete a tuple which does not exist:.

I want OpenFGA to silently ignore this "error" and to continue running the rest of the transaction. Is this possible?

[rhamzeh]

Hi @Valkryst - that's definitely a highly requested feature and we have plans to start working on it in a way that allows user control. AKA you have to opt-in to ignoring those errors.

For some background on why we hesitate to make this the default, checkout this thread here: https://github.com/orgs/openfga/discussions/307#discussioncomment-9218151

That was the reason we introduced non-Transactional checks in the SDKs, potentially we may allow even ignoring those errors in non-Txn mode on the SDK if we see the user need and we find that it is risky and/or slow to allow this on the server itself.