fix(limit-count): refresh the delayed-sync quota after the local delta expired

[nic-6443]

With delayed sync, a node that only rejects can stop refreshing its cached quota, and then it keeps rejecting on stale numbers until the quota itself expires.

The periodic sync flushes a key only while its local delta is present in the shared dict (sync_key, if delta then). That entry is created by incr(..., 0, 2 * window), and init_ttl only applies on creation, so the entry expires two windows after it was first written, whatever happens in between. Admitted requests recreate it; rejected ones don't. So once it expires on a node that is rejecting everything, the timer still runs for the key but skips the flush, and the cached quota is never refreshed again. The next refresh only happens when the cached reset runs out.

With a sliding window this matters a lot. The cached quota carries the previous window's weight as of the last sync, so the node keeps applying a weight of ~0.9 for the rest of the window instead of letting it decay. In a two-node test at 2× the limit, one 10s window admitted 9 requests where an exact sliding window would have admitted 100, because both nodes stopped syncing about 1s into the window. A fixed window isn't affected in practice: within a window the remote count only grows, so a stale cached quota can't wrongly reject, and the window end coincides with the cached reset, which forces a refresh.

The fix flushes a missing delta as 0 instead of skipping it. That refreshes the cached quota exactly like the existing flush of a zero delta, which already happens whenever the entry is present but empty. A failed shared dict read still skips the flush as before. When there was no local delta and Redis is unreachable, the fallback limiter is skipped: there is nothing to account for locally, and charging it the existing minimum of 1 would let a node that only rejects inflate its fallback count on every sync. The path where the entry exists, including a value of 0, is unchanged. For the same reason, sync_to_shm no longer creates an empty entry when nothing was flushed, so a zero-delta refresh doesn't later look like a pending delta.

t/plugin/limit-count-redis-delayed-sync3.t reproduces it without waiting two windows. It exhausts the quota, drops the local delta entry as its expiry would, frees the quota in Redis, and checks that a rejected request schedules a sync that lets the next request through. It returns 200 200 503 503 503 without the fix and 200 200 503 503 200 with it. A second case, a fixed window against an unreachable Redis, drops the entry and checks that the failed sync leaves the fallback counter alone. It goes from 1 to 2 without the fallback guard and stays at 1 with it. A third case covers a zero-delta refresh followed by a Redis error (a non-integer counter). Without the change in sync_to_shm, the fallback count goes from 0 to 1.

No documentation change: the documented delayed sync behavior doesn't change.

• I have explained the need for this PR and the problem it solves
• I have explained the changes or the new features added to this PR
• I have added tests corresponding to this change
• I have updated the documentation to reflect this change
• I have verified that this change is backward compatible

[Copilot]

🟡 Changes recommended

A successful zero-delta refresh can recreate an empty entry that causes incorrect fallback accounting during a later Redis outage.

1 open finding

• Zero-delta refresh can create negative fallback accounting · New

What changed in this PR

This PR refreshes cached limit-count quotas after delayed-sync delta entries expire, preventing stale rejections.

Changes:

• Flushes missing deltas as zero to refresh quotas.
• Skips fallback accounting when the delta is absent.
• Adds regression tests for quota refresh and fallback accounting.

File	Description
t/​plugin/​limit-count-redis-delayed-sync3.t	Tests expired-delta refresh and Redis failure handling.
apisix/​plugins/​limit-count/​delayed-syncer.lua	Refreshes missing deltas and guards fallback accounting.

🧠 Review effort: Balanced

---

Give feedback about Copilot approvals in this survey to enter a drawing for a $150 gift card.