Looks like there is more going on here: ``` zed sc...
# spicedb
u
Looks like there is more going on here:
Copy code
zed schema read
Error: rpc error: code = OutOfRange desc = invalid zedtoken: revision has expired
However, getting a resource without specifying a consistency does work (this is all fake data):
Copy code
zed relationship read project
project:project1 project_admin superuser:project1_superuser1
project:project2 project_admin superuser:project2_superuser2
So, I'm not sure right now how to get the schema that is currently loaded. I'd restart the pod and load a new one, but if this is a unique situation I don't want to "fix" it yet.
Here's a chunk of the K8s log from the ReadSchema request. Not sure it provides anything beyond what zed reports:
Copy code
{
  "insertId": "vnzhmnhtssavm2rq",
  "jsonPayload": {
    "grpc.time_ms": "0.258",
    "grpc.code": "OutOfRange",
    "grpc.service": "authzed.api.v1.SchemaService",
    "protocol": "grpc",
    "grpc.component": "server",
    "grpc.error": "rpc error: code = OutOfRange desc = invalid zedtoken: revision has expired",
    "peer.address": "127.0.0.1:45446",
    "requestID": "e694d939a5e95748146cbfaee65f23e4",
    "grpc.method": "ReadSchema",
    "grpc.start_time": "2023-03-08T23:19:03Z",
    "message": "finished call",
    "grpc.method_type": "unary",
    "level": "warn"
  }
}
j
I just spun up a local v1.17 spicedb instance with in memory and loaded a schema and rels and a
zed relationship read --consistency-full
worked for me
did you provide any other flags or leave the instance running for a long time or something?
u
It's been running since March 4 and was deployed from spicedb-operator v1.20 using the example in the readme on https://github.com/authzed/spicedb-operator.
The data was imported from an exported schema and dataset from the playground, but I don't have that file any longer.
It's currently running v1.16.2 in the deployment.
If this isn't supposed to happen, I'm happy to delete this pod and load it back up with data. But if there's anything else you'd like me to try before I do that, let me know.
j
This is definitely not supposed to happen, but also in-memory is typically for just testing and obviously isn't robust for running for long periods of time. I think you should create an issue on the SpiceDB repo documenting exactly the steps you followed to ultimately get that error and we can make sure it's tracked in case others encounter it and we can collect more info on the bug.
u
Sounds good. I'll also see if it reproduces with a fresh pod. Thanks!
v
I reproduced the problem and proposed a fix in https://github.com/authzed/spicedb/pull/1200 In the meanwhile, you can workaround the issue by issuing requests with
MinimizeLatency
consistency
3 Views