what was it?

So in the keychain I changed the zed entry to allow all applications instead of only allowing the

zed

application defined

that's odd

Maybe it's because of the migration from my old to new machine. I used Apple's utils to move everything from my home to the new one. I did merge the previous and new local account. Maybe the entry was still there but not refering the right binary?

ah

that could be it

(The migration was from a amd64 to arm mac)

Well, it's good now! A huge thank you for all the help 😄

sorry for the trouble :/

It's not often you use software with people that reactive to help

It's ok, i feel lik it's really an edge case

TBH i've got all sort of trouble by trying to keep the config files and not the application when migrating

yeah, that's why I did a full clean setup on my ARM mac

just copied over my project files and installed everything else from scratch

That was definitely a wise choice

haha this is what mine looks like from all the zed versions

Hey! We recently started looking at the watch API to maintain some secondary indices but have run into some issues. We have a worker application that watches a single objectType using the watch service, updates a secondary index, and keeps track of its current position using the ZedToken. We have some quite bursty activity and noticed when 15-20 relations are created in quick succession our watch API gets immediately disconnected with this error: "rpc error: code = ResourceExhausted desc = watch disconnected: watch fell too far behind and was disconnected" I’m assuming its because our worker is pretty slow at churning through updates, but equally I was hoping it would be able to fall a bit further behind and recover without causing much issue.. I took a quick look through the postgres datastore implementation and can see where the err is raised but couldn’t really find any obvious cause. Is there anything you guys would recommend I look at that might help narrow down the issue or is it something you’ve commonly seen before?

@nsains if you simply record the changes and process them async, does it still happen?

Yeah it seems to, even performing no work in there actually (just logging the change to console) seems to eventually disconnect the watch client if enough changes are created to target resource in quick enough succession. I think the one caveat to this is that we're using a self-generated .NET client, reckon that might be the cause?

Question for the authzed folks; The API Dispatch Estimation doc states A dispatched operation is a single non-cached operation performed by Authzed to resolve the answer to the API request. Are the dispatched operations outlined in that serverless document the same as the permission checks in the dedicated page?

unlikely. Its possible its something within the postgres driver, since its writes can be heavy. Please file a bug

I was trying out the example in spice-operator and keep getting reference errors for kustomize resources. They are referencing folders and kustomize is look for files. Am I missing something?

If dedicated page you mean the billing tab on app.authzed.com, yes. We also have another product that is called Dedicated, which does not charge by dispatches, but rather is reserved compute

are you making sure to run it from the examples directory in a fully checked out repo?

Yes it was a fresh clone. Assume I run the supply command at the same level as the readme for the example

can you share the error you're seeing?

Yeah I see the following

kubectl apply --server-side -k  .
error: rawResources failed to read Resources: Load from path cert-manager failed: 'cert-manager' must be a file (got d='/code/authzed/spicedb-operator/examples/cockroachdb-tls-ingress/cert-manager')
exit status 1

Have added it here , https://github.com/authzed/spicedb/issues/439

Yeah I see the following

Hi, when I delete a relationship from the Playground and import in back in, the relationship still appears?