Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Guards by ingress

Which of a channel’s guards run on which ingress, and the order they apply in. A channel is reachable on up to five ingresses, and each guard runs on the ones marked Yes.

Description

GuardHTTP syncHTTP /asyncKafkachannel_callCron
rate_limitYesYesYesYesNo
principal_rate_limitYesYesNoNoNo
authYesYesNoNoNo
origin_allow_listYesYesNoNoNo
validation_logicYesYesYesYesYes
deduplicationYesYesYesNoNo
cacheYesNoNoNoNo
backpressureYesYesYesYesYes
oauth2_loginYesNoNoNoNo
timeout_msYesYesYes¹YesYes

¹ Clamped to a transport ceiling. See Timeouts. Every No cell is deliberate; the owning section below states why.

The Cron column is mostly No because that ingress has no caller at all, which is a stronger statement than Kafka’s “the caller authenticated elsewhere”. A cron channel is refused these keys at authoring time rather than storing them and ignoring them — see Cron transport.

Order of application

Guards run in a fixed order: rate limit → auth → origin allow-list → validation → deduplication → cache lookup → backpressure → oauth2_login. Four consequences follow.

  • A rejected request (bad origin, failed validation) still consumes a rate-limit token.
  • A replayed idempotency key answers 409 before the cache is consulted.
  • A cache hit never consumes a backpressure permit, and a request shed by backpressure releases its idempotency claim.
  • oauth2_login runs last, after the backpressure permit, because its callback leg makes a round trip to the identity provider. That call must be bounded by the channel’s concurrency cap. The consequence is that validation_logic sees the request and not the grant — the grant is what the workflow is for.

Last verified 14 September 2026