Hello! We've been testing a new kubernetes deploym...
# spicedb
b
Hello! We've been testing a new kubernetes deployment of spicedb and noticed some interesting verbose/debug dispatch logs. We were wondering if this behavior is normal. thread ->
zed schema read/write
is working fine but with error logs
caching seemingly working for some operations but not others - though this could depend on where the request started, it seems like consistent behavior which implies not
also curious about the
check=0, dispatch=0
response from one of the requests here
j
those errors are normal
they should be reduced in scope
the check=0, dispatch=0 is just for tracking the amounts made
what version are you running?
f
of spicedb & zed
b
👍 good to know, should we be concerned that the
permission expand
checks seem to never cache?
j
no
there is no caching on expand
f
(yet)
j
yet
b
zed 0.4.1
and we're working off of an internal fork of spicedb
could you expand a bit on the
the check=0, dispatch=0
being tracking specific and not concerning?
f
they are data sourced from gRPC (http2) trailers from processing the request. Not all RPCs dispatch (or cache) and subsequently they're not useful on all endpoints
The metadata can help you understand how complex the request was to process (and can help you identify hotspots). We also use it to charge users on the Authzed.com managed service.
There's a little bit more info here: https://docs.authzed.com/authzed/pricing
b
thanks for the help! Will take a look
f
It should be considered a bug if SpiceDB doesn't at least report 0,0 from any particular endpoint, though.