Hey guys, I have strange behavior: 1 - I sent a write request and got response at 11:37:25.102:

'RESPONSE: 200 - {"writtenAt":{"token":"GgoKCENQcUh1MnM9"}}'

2 - Then I sent another write request and got second response at 11:37:25.138:

'RESPONSE: 200 - {"writtenAt":{"token":"GhIKEENQbUh1MnNRQkJvREFBRUM="}}'

3 - Then I did

check

request with token from step 2 at 11:37:25.712:

'{"consistency":{"atLeastAsFresh":{"token":"GhIKEENQbUh1MnNRQkJvREFBRUM="}}'

but as response I got checkedAt with token from step 1

{"checkedAt":{"token":"GgoKCENQcUh1MnM9"}

How could it be possible?

hi, which datastore are you using? are these 2 writes very close to each other? (potentially concurrently)?

Postgres They are very close to each other (milliseconds). We orientate, that if we get response from a write request with token, that means that the transaction is done, is it right?

I'm going to refer to this thread: https://discord.com/channels/844600078504951838/844600078948630559/1194690184151847012

I don't think that this is the same case, as in that thread, cause I already use the same token from write request in my checks

at first glance, the longer second zedtoken likely indicates that it overlapped with the first transaction

how could we solve this overlapping issue? we already used way "read own writes" - we passed zedToken from write request in the following after it check request, but got outdated response with other zedToken

are you issuing a check immediately after every write?

Yes, after each write request our flow assumes checks those permissions. We cannot change this flow. To save consistency we add to

check

requests with token from the

write

request, and orientate that using

atLeastAsFresh

policy with this token guarantees us the correct permissions. The same permissions that we just wrote. But somehow, even if we use this token we take an incorrect answer, that permissions do not exist.

My rough understanding is that, based on the Postgres internals SpiceDB uses, it is currently not possible to determine causal ordering of overlapping transactions, so something like this can happen. But I to also understand this is not what one would expect if you use

at_least_as_fresh

semantics. @Jake rewrote the postgres datastore a while back and he may able to better clarify why this happens.

v1.21.0