Copilot commented on code in PR #14017: URL: https://github.com/apache/apisix/pull/14017#discussion_r4217862614
########## docs/en/latest/plugins/limit-count.md: ########## @@ -2195,6 +2195,6 @@ With delayed synchronization (`sync_interval`), the counter shared through Redis * `delayed_sync.synced_count`: the count of the current window in Redis at that time. * `delayed_sync.local_delta`: what this APISIX instance counted since then and has not synchronized yet, excluding this request. -`current_window.count` is then an estimate, `synced_count + local_delta + cost`, that does not include what other instances counted since their last synchronization. For a sliding window, `current_window` and `previous_window` describe the windows at the time of the last synchronization: the weight applied to the previous window is fixed at synchronization time, so `previous_window.weight` is the weight that was used for this request, not the weight at `evaluated_at_ms`. The snapshot is only refreshed after its window has ended, so a request arriving a few milliseconds after the window boundary is still checked against the previous snapshot, and its `evaluated_at_ms` is then later than `current_window.end_ms`. +`current_window.count` is then an estimate, `synced_count + local_delta + cost`, that does not include what other instances counted since their last synchronization. For a sliding window, `current_window` and `previous_window` describe the windows at the time of the last synchronization: the weight applied to the previous window is fixed at synchronization time, so `previous_window.weight` is the weight that was used for this request, not the weight at `evaluated_at_ms`. The snapshot is replaced at every synchronization, which runs within `sync_interval` after a request, and when it expires at the end of its window. A request that arrives after a window boundary but before the next synchronization is still checked against the previous snapshot, so its `evaluated_at_ms` can briefly be later than `current_window.end_ms`. Review Comment: This line appears to have dropped the leading `|` used by the surrounding Markdown table rows (it previously started with something like ` |...`), which can break table rendering. Also, the clause “...synchronization, which runs within `sync_interval` after a request, and when it expires...” reads ambiguously as if the synchronization runs “when it expires”; consider splitting into two sentences or rephrasing so it’s clear the snapshot is replaced on sync and refreshed again on expiry. ########## docs/zh/latest/plugins/limit-count.md: ########## @@ -2196,6 +2196,6 @@ nginx_config: * `delayed_sync.synced_count`：当时 Redis 中当前窗口的计数。 * `delayed_sync.local_delta`：该 APISIX 实例自那以后计入、尚未同步的值，不含本次请求。 -此时 `current_window.count` 是估算值，即 `synced_count + local_delta + cost`，不包含其他实例自各自上次同步以来的计数。对于滑动窗口，`current_window` 和 `previous_window` 描述的是上一次同步时的窗口：上一个窗口的权重在同步时就已确定，因此 `previous_window.weight` 是本次请求实际使用的权重，而不是 `evaluated_at_ms` 时刻的权重。快照只在其窗口结束之后才会刷新，因此在窗口边界之后几毫秒内到达的请求仍按上一次的快照判定，此时它的 `evaluated_at_ms` 会晚于 `current_window.end_ms`。 +此时 `current_window.count` 是估算值，即 `synced_count + local_delta + cost`，不包含其他实例自各自上次同步以来的计数。对于滑动窗口，`current_window` 和 `previous_window` 描述的是上一次同步时的窗口：上一个窗口的权重在同步时就已确定，因此 `previous_window.weight` 是本次请求实际使用的权重，而不是 `evaluated_at_ms` 时刻的权重。快照在每次同步时都会被替换（同步会在请求之后 `sync_interval` 内进行），在窗口结束、快照到期时也会刷新。在窗口边界之后、下一次同步之前到达的请求仍按上一次的快照判定，因此它的 `evaluated_at_ms` 可能短暂地晚于 `current_window.end_ms`。 Review Comment: This line also appears to have dropped the leading `|` that keeps it inside the surrounding Markdown table (previously it began with ` |...`). Restoring the leading pipe (and consistent indentation) will prevent the table from rendering incorrectly. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
