Struct LimitGuard 

pub struct LimitGuard<'a> { /* private fields */ }

v1.4.106 codex 0538 F3 (P2): LimitGuard architecture — accepted-quota 模型而非 attempted-quota.

问题 (F3 root cause): 旧版 check_and_commit / check_full_skip_rate 在限额检查通过的瞬间直接累加 daily counter, 即便后续 backend 调用失败 退单也不会回滚 — 用户的 daily quota 被 “attempted” 单消耗 = 攻击者发 N 个 高金额无效单可耗尽合法用户 daily quota.

修法 Option B (本次实装): 引入 LimitGuard RAII pattern:

1. RuntimeCounters::check_limits(...) — 全部检查 (含 rate + per-order cap + daily peek), 但不写 daily counter → 返 Result<LimitGuard, LimitOutcome>.
2. caller 拿 LimitGuard, 调 backend, 成功后调 guard.commit_daily() 才把 daily counter 实际写入.
3. 失败 → drop(guard) 不写 counter, 配额自然归还.
4. rate window 在 check_limits 已 commit (rate 是请求节流不是 quota 退单不该回收 rate budget — 攻击者重试也算 rate 消耗).

legacy compat: check_and_commit / check_full_skip_rate 内部仍 调用 check_limits 链路, 但 wrapper 立即 commit daily (保留 v1.4.105 行为). 新调用方 (v1.4.106+ trade handler) 应迁移到 check_limits + 显式 commit.

Implementations

impl<'a> LimitGuard<'a>

pub fn commit_daily(self) -> Result<(), LimitOutcome>

把 pending daily delta 写入 counter (accepted-quota commit).

通常 caller 在 backend 调用 成功 后调; backend 失败时 drop(guard) 不写, daily quota 不消耗.

重要: commit_daily 是 idempotent — 同一 guard 多次调只写一次 (pending 取走后 set None). 多 caller 共享一个 guard 时安全.

返回 Ok(()) if commit 成功 (或 no-op); Err(LimitOutcome) if commit 时 cap 被超 — 不应发生 (peek 已校验过), 但并发场景下两 guard 同时 commit 可能撞 cap, 此时第二个 commit 拿 ThroughputReject.

pub fn has_pending_daily(&self) -> bool

是否有 pending daily delta (false = no-op commit, e.g. mutation_no_exposure)

Trait Implementations

impl<'a> Debug for LimitGuard<'a>

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.