we don't require any schema changes to be made while the system is under load

you can enable the experimental watch schema cache, that should reduce significantly the number of namespace queries

great, thank you

it's still experimental and there may be bugs, but we are committed to eventually GAing it, it has proven very useful

hi @vroldanbet , is this the right channel to submit a crash report? I pointed our spicedb deployment to a different postgres server (I'm not sure in which way it is different from the previous one) and the watching cache crashed:

{"level":"info","revision":"CNT9lQM=","count":0,"time":"2025-02-18T13:34:11Z","message":"populated caveat watching cache"}
{"level":"debug","revision":"CNT9lQM=","watch-heartbeat":60000,"time":"2025-02-18T13:34:11Z","message":"beginning schema watch"}
{"level":"debug","time":"2025-02-18T13:34:11Z","message":"schema watch started"}
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x134ff0a]
goroutine 706 [running]:
github.com/authzed/spicedb/pkg/datastore.(*RevisionChanges).MarshalZerologObject(0x0, 0xc000b7a230)
    /home/runner/actions-runner/_work/spicedb/spicedb/pkg/datastore/datastore.go:72 +0x2a
github.com/rs/zerolog.(*Event).appendObject(0xc000b7a230, {0x3a759e0?, 0x0?})
    /home/runner/go/pkg/mod/github.com/rs/zerolog@v1.33.0/event.go:211 +0xa5
github.com/rs/zerolog.(*Event).Object(0xc000b7a230, {0x3473354?, 0x0?}, {0x3a759e0, 0x0})
    /home/runner/go/pkg/mod/github.com/rs/zerolog@v1.33.0/event.go:227 +0x18b
github.com/authzed/spicedb/internal/datastore/proxy/schemacaching.(*watchingCachingProxy).startSync.func2()
    /home/runner/actions-runner/_work/spicedb/spicedb/internal/datastore/proxy/schemacaching/watchingcache.go:264 +0xabd
created by github.com/authzed/spicedb/internal/datastore/proxy/schemacaching.(*watchingCachingProxy).startSync in goroutine 623
    /home/runner/actions-runner/_work/spicedb/spicedb/internal/datastore/proxy/schemacaching/watchingcache.go:185 +0x20f
Starting service..........Max attempts reached

yeah this is the right place. Can you open an issue? What do you mean "to a different postgres server"?

it is v1.40.0

track_commit_timestamp

is required for Watch API, which is used by the watch schema cache. With that I think we can probably reproduce it. > i'm afraid i can't open an issue, company policy doesn't seem to allow it as an OSS maintainer, that's sad to hear 😢