docs: align the stall window comments with the new metering
_validate_stall still guards stall_window_s >= max ttft_timeout_s, but its stated reason no longer holds: TTFT waiting is productive time and never reaches the stall account. The check is harmless and stays, so the docstring now says why it is kept rather than implying a live hazard. .env.example dropped the "must be >= max TTFT" advice for what the window actually measures.
This commit is contained in:
@@ -238,7 +238,14 @@ class GatewaySettings:
|
||||
)
|
||||
|
||||
def _validate_stall(self) -> None:
|
||||
"""stall 窗口须 ≥ 最慢源 TTFT 上限,防把正常慢首包误判为卡死。"""
|
||||
"""stall 窗口须 ≥ 最慢源 TTFT 上限(保守冗余,见下)。
|
||||
|
||||
原理由是"防把正常慢首包误判为卡死"。issue #8 起 stall 只累计**非
|
||||
生产性等待**(429 退避、配额轮询、熔断冷却),TTFT 等待属生产性时间、
|
||||
已不计入 stall 账,该误判在机制上不再可能。校验本身无害且不会误拒
|
||||
任何合理配置,故保留——删除它需同步改动 ARCHITECTURE.md §7.3 的契约
|
||||
补强 G6,超出 issue #8 的范围(2026-08-06 人类定夺)。
|
||||
"""
|
||||
ttfts = [s.ttft_timeout_s for s in self.sources if s.ttft_timeout_s is not None]
|
||||
if ttfts and self.backpressure.stall_window_s < max(ttfts):
|
||||
raise ValueError(
|
||||
|
||||
Reference in New Issue
Block a user