Hi permitio team, Does PDP have recovery mechanisms when a callback has its saved status set to false

Hi @B22DCCN393 Nguyễn Việt Huy, I'm an AI assistant for Permit.io. I'll analyze available sources and get back to you shortly.

Hey, thanks for reaching out ! It seems our team is a little busy right now, a human will be with you within the next hour or so. In the meantime, can I help you ?

Based on the available documentation, I don't have specific information about PDP recovery mechanisms when a callback has its saved status set to false. The documentation covers callback registration (1) , listing callbacks (2) , and unregistering callbacks (3) , but doesn't explicitly detail recovery mechanisms for callbacks with failed or false saved status. To help investigate this issue, could you provide: 1. Which Workspace / Project / Env you are using 2. What calls you are performing (as SDK code or CURL) 3. Which PDP version you are running 4. Relevant logs from your PDP This information will help our engineers investigate the callback behavior you're experiencing.

I’m concerned that PDP might crash because of any synchronization error, even if it has been configured correctly

you can use offline mode @Ask Inkeep

Thanks for tagging me @Or Weis. I'll look through relevant sources and get back to you shortly.

@Or Weis Do you plan to store them in a database in the future, and which database would be the best choice for this use case?

You mean the backup files? no.

If a project has millions of users and many relationships, I’m concerned that the data could become very large

the PDP itself is essentially your database, these backup files are essentially database snapshots. It doesn't make sense to save databases in other databases. Such snapshots are usually managed as part of your storage/ volume mounting system.

With your experience managing PDP, how much OPA data would a large project typically contain? And I can estimate the data size for around 1 million users, but the number of relationships could grow exponentially

Can you tell us a little bit about your use case, which company you work for, what project you're working on, and what are your requirements for it?

I would like the Permit team to have a mechanism that allows connecting directly to the database through the SDK, because some of my projects already existed before using Permit.

We don't have a feature like that

Yeah, I work on company projects where the parent instances are always departments, and beneath them is a graph of child instances. Therefore, if there are any mistakes in the developers’ logic, it could lead to inconsistencies, and over the years this could grow to hundreds of millions

Most of our customers have such hierarchical setups. Data synchronization is always somewhat of a challenge, but it's usually not a significant one - especially not due to "devloeprs logic. This challenge would exist in any data replication. Whatever you decide to copy onto the control plane would be replicated exactly onto your OPA instances. You can expose the port for OPA and talk to it directly and list its data and comapre it to whatever you'd like. Though that's not something needed in most cases, and from what you described I don't think it is needed in yours either

You’re wrong. During development, we can run into situations like: • A project already exists but its old data hasn’t been synchronized to Permit. We can write a script to sync it to Permit, but there are many similar projects, so we end up having to recreate the script from scratch each time we want to sync. • Another case is when the initial dataset is being synchronized with Permit during development, but if a developer forgets to assign permissions or relations, they won’t know what data is missing in order to delete and test again. When the dataset grows to over 100 entries, it becomes impossible to understand what’s missing just by looking at a bunch of meaningless UUIDs. The previous solution becomes even harder because we first have to identify which instances need to be deleted before we can delete them. As a result, we end up having to create two additional scripts to support this process. That’s what I meant. If you think it’s unnecessary, that’s fine—I’ll still stick with this traditional approach in the future

Wishing you all the best

Don't dismiss this as an issue; I've reviewed your Opal source code and noticed a behavior where the PDP will pull back all data if there are any problems with the Websocket stream. That's why I'm concerned about this.

That's a feature, not a bug.

oke thanks