@User Any further thoughts on the issue ?

I've got a meeting in a few minutes, but then I'm going to try and reproduce the issue locally.

appreciate it, thanks

https://github.com/romilshahdev/spicedb (just fyi on steps followed )

@romil I think you're just missing the

serviceAccountName: "spicedb"

in your podspec in the spicedb deployment

Thanks for looking into it, it did work 👍👍

Howdy! We're running spicedb on EKS backed by RDS... however, I'm trying to debug why I occasionally see dropped connections and errors concerning:

failed to connect to <rds-instance>.us-east-1.rds.amazonaws.com user=spicedb_admin database=spicedb`: dial error (dial tcp <vpc-ip-addr>:5432: operation was canceled)

Does anyone have tips on how to debug this. Pods are stable with no restarts, pods and rds are in the same VPC... It doesn't seem to be correlated with load. I'm curious if there are any more logs I can abstract from spicedb about this issue, to include in AWS support ticket (wanna make sure it's not DNS related)

we've had that problem on a past project with DNS and hitting RDS connection limits

Ah ok, so I might get around this by upping the connection limit

any other hints 🙂 ?

nope, just make sure that the connection pooling config for spicedb matches your connection limit profile for your specific RDS instance size

Roger. Thanks Jake

Hello, I have spiceDB configured with the dispatcher

--dispatch-upstream-addr=kubernetes:///spicedb.authz:50053

. I see that read and write endpoints are all working fine but the call for lookup/ expand and check are failing with the below said error

last connection error: connection error: desc = \"transport: Error while dialing dial tcp <xxxx>:50053: connect: connection refused

I don't see any other error on the pod logs, any view?

{"level":"warn","grpc.component":"server","grpc.method":"CheckPermission","grpc.method_type":"unary","grpc.service":"authzed.api.v1.PermissionsService","peer.address":"127.0.0.1:33296","protocol":"grpc","requestID":"3bd3b49e05697e5f7b48b1ebad2dade7","grpc.start_time":"2022-04-14T13:04:17Z","grpc.code":"Unavailable","grpc.error":"rpc error: code = Unavailable desc = last connection error: connection error: desc = \"transport: Error while dialing dial tcp 
<xxxx>:50053: connect: connection refused\"","grpc.time_ms":"0.597","time":"2022-04-14T13:04:17Z","message":"finished call"}

Version of Spicedb is :

quay.io/authzed/spicedb:v1.6.0

@romil can you do

kubectl describe

on your deployment?

and also

kubectl describe service spicedb

Is anything specific that you like to highlight? dont see any error as such under events.

yes I would like to see the service definition to make sure that the port 50053 is there, and I would like to see the deployment definition to make sure that the pod is exposing that port

you can do those things

also if you could grep the startup logs for the pod to see if there is a log line like:

9:47AM INF grpc server started listening addr=:50053 network=tcp prefix=dispatch-cluster workers=0

If I do a check that must be at least as fresh as some zedtoken and the cache is not at least that fresh, what work does spicedb do? Does it compute my check from scratch?

yep

it'll reuse the cache where possible (if any subproblems are cached at least as freshed as the zedtoken)

but if there is no cache for any subproblems, it is fully recomputed

I see. Thank you!

also keep in mind the scenario where everything is not caught up will only likely be immediately after the write occurs

if you use the zedtoken 10 minutes after it was minted, its likely most of the caches are beyond its requirement

If I have this schema:

definition user {}

definition foo {
  relation creator: user
  permission read: creator
}

definition bar {
  relation foo: foo
  permission read: foo->read
}

what strategy would I use for saving zedtokens so that I could use the cache to get all `bar`s that some

user

can

read

via

LookupResources

? So far I’ve been relying on fully consistent lookups but for some users that is far too computationally intensive

Like, if I’m modifying relations between

user

and

foo

I know I can save zedtokens for the

user

for this purpose. But I’m not sure what to do with the nested case

so there are a few options

(1) just accept that there will be a slight lag (on the order of seconds)