Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -280,7 +280,7 @@ A value outside its range stops Egret at startup, for example *governance.opa.ba
- **Body deadline.** An admitted request must deliver its whole body within `body_read_timeout_ms`, or it gets 408. 5 s covers a 24 MiB body at about 40 Mbit/s; a 64 MiB body needs about 110 Mbit/s. Raise it on a slow link.
- **In flight and parsing.** Egret counts bodies in 4 MiB units: at most 64 units (256 MiB) in flight before authentication, and 16 units (64 MiB) being parsed at once. A request reserves its declared `Content-Length`, or its route's whole limit when it declares none. A request that cannot get its units within 1 s gets 503 `{"error": "busy"}`, and its body is never read. A larger `batch_body_limit_bytes` lets one body take more of the same budget; it does not raise the memory bound.
- **Rebuild delay.** Snapshots are rebuilt within about 1 s of a policy change.
- **Shared tag service.** After a policy or tag change, the OPA surface keeps answering from the previous snapshot until each affected profile is rebuilt. Profiles rebuild one after another on the 1 s refresher, so when many profiles share one tag service, a tag change reaches the last of them after roughly N rebuilds. On a loaded dev machine the last profile became current about 0.4 s after the change with 5 profiles sharing one tag service, about 1 s with 10 and about 3.5 s with 20, and the refresher's 1 s period comes on top. The time also grows with the total number of grants and rules on the installation.
- **Shared tag service.** After a policy or tag change, the OPA surface answers from the previous snapshot until each affected profile is rebuilt. Profiles rebuild one at a time on the 1 s refresher, so when N profiles share one tag service, a tag change reaches the last of them after about N rebuilds. On a dev machine with profiles of about 1 000 policies each, one rebuild took about 50 ms. The last profile became current about 0.25 s after the change with 5 profiles, 0.5 s with 10 and 1 s with 20. Up to 1 s more comes on top while the change waits for the refresher's next tick. A profile's rebuild reads only the grants and rules on the catalogs that profile reaches, plus every tag rule, so grants on other catalogs do not slow it.
- **Other gaps.** An external Trino 483 engine on its own compiled profile cannot run any query: it gets no infrastructure rows (KI-354). The mask `{col}` placeholder is substituted unquoted, as with Ranger. StarRocks has no OPA mechanism.

## Further reading
Expand Down
Loading