Batch Error handling and response from the server

[ghstahl]

I find that asking a service to delete something that isn't there as being a soft error. Also writing something that is already there is also a soft error. I wrote a wrapper around the go-sdk writes that eats those errors and returns a nil. These are not errors to me.

That worked great until I started writing in batches.

This is the result.

{
  "deletes": {
    "tuple_keys":[{
        "object": "user_repo:*",
        "relation": "member",
        "user": "userA"
    },{
        "object": "user_repo:*",
        "relation": "member",
        "user": "garbage"
    }]
  } 
}

{
  "code": "write_failed_due_to_invalid_input",
  "message": "cannot delete a tuple which does not exist: user: 'garbage', relation: 'member', object: 'user_repo:*': invalid write input"
} 

The server did nothing. The tuple that was supposed to be deleted was not. I suspect that the server validates that everything I want deleted is there and if it isn't it bails out. All or nothing!

As a client user I would expect the following when writing.

1. The write payload has directives that tell the server to eat soft errors
2. The server responds with an array of failed hard errors. This is not a 200. I think that even this should be configurable. Do what you can, tell me where you failed. Let me decide if it's an "All-Or-Nothing" action.

A hard error for me is I try to write a tuple that isn't modeled. This includes deleting a tuple that doesn't match the model and obviously doesn't exist.

If I get my model right and only send in tuples that match, then I will NEVER get an error because everything is a soft error.

I would think that the settings for this are both server wide and per call, where the call one overrides the server-wide settings.

This is a soft error because it matched the model:

{
  "deletes": {
    "tuple_keys":[{
        "object": "user_repo:*",
        "relation": "member",
        "user": "garbage"
    }]
  } 
}

This is a hard error because there is no model for it.

{
  "deletes": {
    "tuple_keys":[{
        "object": "garbage:more_garbage",
        "relation": "garbage",
        "user": "garbage"
    }]
  } 
}

[ethanjcohen]

I'd like to add that this feels important so that I can write "dumb" integration code - ideally I could consume events from my system, transform those into relations, and write those relations in a batch, all without having to think about what's already stored. I should be able to write a relation multiple times - there are cases where it's preferred to have simpler integration code that might write twice, and prefer readable code vs over optimizing and ensuring a write only occurs once. As stated above, this becomes harder if I want to implement batching.

[uncvrd]

Agreed on this stance - would be nice to not have to handle errors for tuples already stored in my database. I'd prefer not to have to write logic to check what's currently in my store, find the diff, and only write what does not already exist. Currently unable to use transactions because of this

[ghstahl]

It also maps to patterns that are used for infrastructure as code. The only important thing is the outcome, not how you got there. In this pattern asking to have a database spun up that is already there isn't an error.
That is actually how I author my tuples. When I ask that a user gets added to an org, a lot of tuples need to be written to achieve what I want. I author a json with all the tuples needed and do a string replace on stuff like {{org_id}}, {{user_id}}, etc.

The final outcome is all that matters.