Table of Contents
Mirrored from
/mnt/DATA/git/govoplan-core/docs/THROTTLING.md. Origin:repository. Active tasks and changing state belong in Gitea issues; this wiki page is durable project context.
Shared fixed-window throttling
Core exposes govoplan_core.core.throttling for security-sensitive endpoints
that need bounded fixed-window counters. Subjects are SHA-256 hashed before they
become store keys. A configured Redis instance provides atomic counters shared
across API workers; development, a missing Redis configuration, and temporary
Redis outages use a bounded process-local fallback. When Redis fails, local
attempts are still mirrored so losing the distributed store does not reset the
active worker's protection window.
Callers define one or more ThrottleDimension values with a controlled
namespace, a subject and a positive limit. They must call check before an
expensive verifier, record after a failed attempt, and may reset the relevant
dimension after successful verification. A blocked decision includes a
retry_after_seconds value suitable for an HTTP Retry-After header.
The first consumer is Scheduling's anonymous participation password challenge.
Its namespace is poll-participation-password; its subject combines tenant,
scheduling request and Poll's non-secret invitation-token fingerprint. Access's
login throttle predates this primitive and should be migrated onto it in a
separate compatibility-preserving slice.