Skip to content

runtime: charge quota before guard check on submit#435

Open
mfw78 wants to merge 2 commits into
feat/advisory-guard-posturefrom
feat/guard-deny-quota
Open

runtime: charge quota before guard check on submit#435
mfw78 wants to merge 2 commits into
feat/advisory-guard-posturefrom
feat/guard-deny-quota

Conversation

@mfw78

@mfw78 mfw78 commented Jul 16, 2026

Copy link
Copy Markdown
Contributor

What

Move the quota charge in VenueRegistry::submit from after the guard check to before it.

Why

The guard is advisory-only today, so a deny always falls through and gets charged regardless of order. But once a guard enforces a deny, charging after the check means a denied caller pays nothing and can retry forever: a free busy-loop DoS against the guard and router. Charging before the check closes that gap ahead of time.

Testing

  • Added repeated_guard_denies_exhaust_the_caller_quota: with a 2-unit quota and a denying guard, the first two submits are charged and admitted, the third is RateLimited, proving a deny loop cannot outrun the quota.
  • cargo test --doc (rustdoc reflects the new charge order).

AI Assistance

Implemented and tested with Claude Code assistance.

Closes #364

mfw78 added 2 commits July 16, 2026 17:19
The submission charge moves ahead of the guard verdict at the venue
registry, so a denied egress spends one unit exactly as an accepted
submit does: a module spamming denied egress exhausts its own budget
instead of looping free once the guard turns enforcing. A regression
test pins the rate limit on a repeated-deny loop.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

runtime: charge quota on guard-deny to close the busy-loop denial-of-service

1 participant