DA Live browse repeats a denied org-config request

An upstream DA Live issue reported that a browse page can request the same organization configuration five times for a user without CONFIG read access. Each call returns 403, and two separate caches plus eviction of failed results repeat the work. An editor may see a slower or noisier workspace, but the trace alone does not quantify user-visible latency.

Confirm the request pattern

Capture a fresh browse load in the browser Network tab and group calls to GET /config/{org}/ by status and initiator. Check the user’s effective permission rather than assuming the 403 is a network failure. Preserve a baseline before changing roles or code.

Distinguish permission from retry policy

A stable 403 for a reader without CONFIG access should not trigger the same retry logic as a transient 401, 5xx, or network error. The upstream issue proposes caching the denial for the page view while retaining retries for recoverable failures. Do not grant CONFIG read merely to silence repeated requests.

Validate the workspace outcome

Compare request count and browse behavior for authorized and restricted users after an upstream fix. Include the permission headers in regression checks because the issue notes that one cache also stores X-da-actions. Keep a customer-facing test on the editor’s actual browsing path.

Adovo’s view

Permission boundaries should be cheap and predictable. A denied read is a valid state, not a signal to ask the server five more times. Authoring reliability improves when the product honors the user’s role and its own cache contract.