we've considered allowing them to be sorted in some fashion

thank you!

but as of right now, they are not

yes, a way to sort zedtokens or else some kind of timestamp for when a write or delete was committed would be very helpful

Can you talk about why it would be useful for you? Generally you should just take the zedtoken and stash it with the relevant data

following this advice here https://discord.com/channels/844600078504951838/844600078948630559/964185568059740260 in order to get a usable zedtoken for calls to

LookupResources

. if we want to prevent concurrent updates from causing a race condition where an older zedtoken could potentially be written last we either need to partition those concurrent writes around the scope of that universal zedtoken which makes scaling up very hard, or we need to be able to do a check-and-set operation that determines if a newer zedtoken has already been written

am i overthinking this do you think? maybe it's not a big deal if that universal zedtoken is sometimes a couple writes behind

> maybe it's not a big deal if that universal zedtoken is sometimes a couple writes behind

that really depends on your application's consistency guarantees

for most applications, they might not even need the zedtoken at all, since the default "window" is ~5s, and being a few seconds out of date isn't the end of the world

however, if you want to mitigate fully against the new enemy problem for all resources via lookup, then you'd need to have a direct ordering of zedtokens

but that is a rare occurrence, I'd imagine

I think my recommendation would be to not use lookup results for guarding permissions at all, use them to show the user their options, but then when the user navigates to that one option do a check

understood. okay i feel like i can move forward. thanks y'all

sorry, one more question on this subject: let's say we have a use case like implementing a DataLoader for a GraphQL schema where we are collecting IDs together to process them as a batch. in that case would you process that set of IDs with individual

CheckPermission

calls?

Sounds right!

cool. thanks again!

do you think a bulk permission check endpoint is something that makes sense for the api, in order to avoid round trips for many lookups? or does grpc handle connections in a way that makes that overhead pretty minimal?

Yeah grpc uses http/2 request pipelining

cool! you guys have thought of everything 😄

@Jake Hello, anything which catches your attention here Jake? seems though no dispatcher error from any of the pod logs, the check , lookup is not rightly dispatched and hence failing over 50053

spec:
  selector:
    app: "spicedb"
  type: "LoadBalancer"

I have used

LoadBalancer

as type rather than

ClusterIP

so that I can access the port by tunneling via

minikube tunnel

Can this be an issue? due to which check, expand api not working ?

Yeah that sounds like it could be the problem. Try to switch it to cluster ip. You shouldn’t need to access the internal dispatch port externally, but if you did you could use kubectl port-forward.

You can create a headless service that kuberesolver can use then another service with LoadBalancer, that way you don't disrupt the internal communication and at the same time you are free to use your LB for your apps to connect to spicedb from outside kube cluster.

To be clear, dispatch, which is on 50053 by default, shouldn’t need external traffic

The traffic on the api server is on port 50051 by default

I'm trying to set

SPICEDB_TELEMETRY_ENDPOINT

as a blank environment variable, but it still uses the default endpoint. Is this a "just me" thing, or can someone reproduce it?

I suspect it's because the default of https://pkg.go.dev/github.com/spf13/viper#AllowEmptyEnv is

false

.

oh interesting I thought I tested this locally

ah, i only tested it with the cobra flag directly