https://authzed.com logo
Join Discord
Powered by
In the past, a ZedToken could be decoded
# spicedb
m
In the past, a ZedToken could be decoded externally to SpiceDb - is that still the case with newer versions?
More context: A request to our API could result in multiple asynchronous requests to SpiceDB. In the past, we collected all ZedToken results from each request and kept the latest so that a subsequent read/lookup would have the more accurate consistency. This was completed in the past by decoding the ZedToken (which was comprised of a Base64 encoding of a timestamp) so we can sort them and retrieve the latest. I believe this has changed - how can we determine which ZedToken from an async batch of requests is the latest?
j
> In the past, a ZedToken could be decoded externally to SpiceDb this was never supported
in fact, the ZedToken documentation explicitly stated not to do so
> kept the latest so that a subsequent read/lookup would have the more accurate consistency.
from... what?
a ZedToken should only be updated on a per-resource basis, and having the "latest" isn't really necessary to avoid New Enemy
m
Okay, let me outline what we are trying to do and maybe that will be more clear: We have a GraphQL API where a request that comes in can cause more than one write request out to SpiceDB asynchronously. The resulting tokens that come back from each request are retained once all async requests are completed. Then a subsequent query to SpiceDB is made to resolve the latest state of some resource - this request is made with the last ZedToken so that we can guarantee consistency (using 
atLeastAsFresh
). How can I determine which resulting token, of the lets say 10 async writes that completed, to pass as the consistency to the final 
lookup/read
request?
We apparently missed the documentation outlining not to decode the tokens, so is there a better way to do this?
j
issue a check at full consistency once writes are completed and record that zedtoken
if that's your intention
longer term, we plan to have an API for this
the problem is that client side comparison is not easy
it is with most datastores, but postgres it isn't
m
alright, so a work around for now is just to request full consistency if we ever write during the lifecycle of the user's request?
j
or issue a check post write
and use that zedtoken
this is for a read-after-write scenario?
m
it is, but more. like read-after-async-writes, so the read has to happen once all async writes that should occur, have completed
so being able to order tokens would allow us to make the most efficient call (i.e. indicate exactly what point in time we want to read at) vs forcing full consistency. But that should work for now
j
so wherever you are currently comparing the zedtokens
issue a fully consistent check at that point
and record the zedtoken then
and then you're guaranteed to have "latest"
m
yea, we would just need to issue the fully consistent - that will work
thanks
j
it could even be a no-op check on an invalid item
PreviousNext
Powered by