Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#930 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
55/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
redis, typescript
Domínio
backend, databases

Direção de pesquisa

Start by tracing the EWMA rate limiter’s Lua script and the code that builds its Redis keys; the issue names the colliding connection and message key patterns. Check how the existing sliding-window strategy stores those keys and inspect the upgrade notes. Done means upgrading with legacy sorted-set keys no longer causes WRONGTYPE errors, with the behavior covered for both connection and message limits.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
TypeScript
Estrelas
829
Forks
234
Merge médio
16h 13min
PRs com merge (30d)
74

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de cameri/nostream

Todas as issues de cameri/nostream

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.