AlinsRan commented on PR #13443:
URL: https://github.com/apache/apisix/pull/13443#issuecomment-4646343109
Good catch — addressed in c844c2aec.
I went with your first option (a versioned key namespace). The fixed-window
Redis counter key now embeds a storage-format version, rendered as `:v1:`:
```
plugin-limit-count<key> -> plugin-limit-count:v1:<key>
```
Pre-upgrade keys never carry the `:v1:` segment, so the new code can never
read an old-format value (remaining quota) with the new meaning (consumed
count). Old keys are simply left to expire via their existing TTL (<=
`time_window`) — no detection/migration step needed, and no over-/under-limit
window.
A few implementation notes:
- The version is passed into the backends at construction
(`limit-count-redis{,-cluster,-sentinel}`) and applied in the single
key-building site (`util.redis_incoming`), so all three policies and the
delayed-sync path stay consistent.
- It's a **dedicated** format version, independent of the plugin `version`
field, so it only needs to be bumped when the stored format actually changes
(not on unrelated plugin releases).
- The only upgrade effect is that existing counters start fresh under the
new key — a one-time reset bounded by a single window, which is predictable and
safe compared to misreading old-format values.
--
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]
