docs: note serialized decision behavior for approval actions

Clarify that approve/reject/cancel decisions for a single approval request should be treated as serialized and not submitted in parallel.
2026-02-26 13:16:32 +00:00
parent 8bb3c1ce12
commit 464524da27
2 changed files with 2 additions and 0 deletions
@@ -158,6 +158,7 @@ Provider user/project assignment views may exclude disabled projects even if his
 - Treat enrollment URLs as sensitive bearer material: do not place them in redirect query parameters, logs, or analytics tags; keep them in one-time server-side flash/session state.
 - If your deployment runs behind reverse proxies, ensure trusted-proxy configuration is strict so spoofed forwarding headers cannot bypass IP-based abuse controls.
 - For approval-driven admin mutations, assume provider-side execution is serialized per approval item; client retries should still be idempotent and bounded.
+- This serialization applies across approval actions (approve/reject/cancel), so clients should avoid parallel decision submissions for the same request ID.
 - Configure OAuth client redirect URIs as HTTPS in production; reserve HTTP for localhost loopback testing only.
 - Assume provider rate limits are enforced per source identity (for example IP) and shared across related auth endpoints.
 - Treat report/export-style provider endpoints as high-cost and expect stricter rate limits.