[BUG] Upgrade from 2.x: EWMA rate limiter hits WRONGTYPE on sliding-window keys left in Redis #930

Describe the bug
After upgrading from 2.x with the existing cache volume, client workers log on every new connection/message:

uncaught error: [ErrorReply: WRONGTYPE Operation against a key holding the wrong kind of value script: <sha>, on @user_script:6.]

2.x used the sliding-window limiter, which stores ${remoteAddress}:connection:${period} and ${client}:message:${period} as sorted sets. Since #476 the default limits.rateLimiter.strategy is ewma, whose Lua script does HGET/HSET on the same key names. The old zset keys stay in Redis until their TTL expires (up to the longest configured period), and until then those clients hit the error path.

To Reproduce

1. Run 2.x for a while (rate-limit keys accumulate in the cache volume).
2. Upgrade to 3.x keeping the volume, start the relay.
3. docker logs nostream shows the WRONGTYPE errors above; redis-cli type <ip>:connection:<period> → zset.

Expected behavior
Upgrading does not require manual Redis cleanup.

System

• Version: 2.1.0 → 3.4.1, default rateLimiter.strategy: ewma, redis:7.0.5-alpine3.16

Workaround we used
Delete only the conflicting legacy keys (7 058 in our case), after which the errors stopped:

for p in '*:connection:*' '*:message:*'; do
  redis-cli -a "$REDIS_PASSWORD" --scan --pattern "$p" | while read k; do
    [ "$(redis-cli -a "$REDIS_PASSWORD" type "$k")" = zset ] && redis-cli -a "$REDIS_PASSWORD" del "$k"
  done
done

Suggestion
Either namespace the EWMA keys (e.g. ewma: prefix) so they cannot collide with sliding-window keys — this also helps when an operator switches strategy back and forth — or make the EWMA script self-healing:

if redis.call('TYPE', key).ok ~= 'hash' then redis.call('DEL', key) end

plus a line in the upgrade notes.