I don't have information in the available sources that documents a way to block or gate

/check

(or

/allowed

) requests on the PDP until data is fully loaded. The sources discuss related but distinct topics: • The PDP caching mechanism covers

/allowed

,

/allowed/bulk

,

/user-permissions

, and

/authorized_users

, but this is about caching decisions, not about blocking requests until data sync completes (1) . • There's a discussion about detecting when

OPAL_DATA_CONFIG_SOURCES

have fully loaded at startup via

/v1/data/system/opal/ready

and

OPAL_OPA_HEALTH_CHECK_POLICY_ENABLED

, but the reporter found that

ready

does not reliably wait for all data sources to finish loading, and this was confirmed as a non-standard/unsupported setup rather than a documented feature for gating checks (2) . Since there's no documented PDP setting or endpoint specifically for holding back

/check

calls until data is current, I can't provide a supported code example for this. Since this sounds like something not working as expected with your PDP/data sync, it'd help to get a few details so this can be looked into further: 1. Which Workspace / Project / Env you're using 2. What calls you're performing (SDK code or CURL) 3. Which PDP version you're running 4. Any relevant logs from your PDP Would you like a general answer based on my broader knowledge instead, or want to share those details?

To learn more, see the sources I considered: [[1] Permit's PDP (Policy Decision Point)](https://docs.permit.io/concepts/pdp/overview) [[2] How to detect all OPAL_DATA_CONFIG_SOURCES have been fully loaded at startup](https://github.com/permitio/opal/discussions/887)

For the read-your-own-writes / consistency scenario you're describing, the relevant documented mechanism is the "Consistent Updates" (local facts uploader) flow. There are two related PDP configurations that touch this:

PDP_LOCAL_FACTS_WAIT_TIMEOUT

— when using SDK proxy facts via the PDP, this is the default time to wait for facts to be available, in seconds (1) .

PDP_LOCAL_FACTS_TIMEOUT_POLICY

— controls what the PDP does if a data update doesn't apply within that timeout period : • `ignore`: responds immediately even if the data update hasn't applied within the timeout • `fail`: responds with a 424 status code if the data update hasn't applied within the timeout There's also

PDP_CONTROL_PLANE_TIMEOUT

, which sets the timeout in seconds for control plane requests, including proxied requests for the Consistent Updates APIs . Beyond these settings, I don't have documentation describing a general mechanism to block all

/allowed

(

/check

) calls until arbitrary delta changes have synced — these configurations specifically apply to the "Send Consistent Updates" / local facts uploader flow, not a blanket gate on every permission check . Since this touches on a specific behavior you're seeing with data timing on your PDP, it'd help to get some details for a closer look: 1. Which Workspace / Project / Env you're using 2. What calls you're performing (SDK code or CURL) 3. Which PDP version you're running 4. Any relevant logs from your PDP

To learn more, see the sources I considered: [[1] Configurations](https://docs.permit.io/concepts/pdp/configuration)

That's a valid concern — the Send Consistent Updates mechanism only guarantees consistency on the specific PDP instance handling the write request, not across a cluster of PDPs (1) . The documentation directly addresses this deployment consideration: For ​*Deployment Recommendations*​, this feature works best when the same PDP instance handles both data creation and permission checks: • ​*Recommended*​: Deploy PDPs as a Centralized PDP or as a PDP Sidecar to your application. This ensures the same PDP instance handles both data creation and permission checks . • ​*Less Optimal*​: Using a PDP Cluster with load balancing, permission checks may be routed to PDPs that haven't received the data update yet . So with 10 PDPs behind a load balancer (a Cluster of Edge PDPs) , this is explicitly called out as a "Less Optimal" pattern for this feature, since a check could hit a different PDP than the one that processed the write (2) . I don't have documentation describing a way to broadcast a "wait until synced" signal across multiple PDPs simultaneously, or a mechanism to force all PDPs in a cluster to sync before permission checks are allowed. The consistency guarantee described is scoped to a single PDP instance per request (1) . Since this is a real architectural limitation you're running into with a multi-PDP deployment, it would help to get some details for a closer look: 1. Which Workspace / Project / Env you're using 2. What calls you're performing (SDK code or CURL) 3. Which PDP version you're running 4. Any relevant logs from your PDP

To learn more, see the sources I considered: [[1] Send Consistent Updates (Read-Your-Own-Writes)](https://docs.permit.io/how-to/manage-data/local-facts-uploader) [[2] Permit's PDP (Policy Decision Point)](https://docs.permit.io/concepts/pdp/overview)