Redis dev entra em MISCONF no Windows (Docker Desktop) e o rate-limit de login para de funcionar silenciosamente

[vagnerdearaujo]

Redis dev entra em MISCONF no Windows (Docker Desktop) e o rate-limit de login para de funcionar silenciosamente

Resumo

No desenvolvimento em Windows + Docker Desktop, se o repositório mora numa unidade diferente de C: (ex.: HD externo D:), o bind mount ./data/redis do docker-compose.override.yml fica quebrado: o Redis não consegue persistir (RDB e AOF falham) e entra em MISCONF (stop-writes-on-bgsave-error). Todo comando de escrita passa a ser recusado com erro — inclusive o INCR do rate-limit.

O efeito colateral pior é que isso desliga o teto de 5 falhas/5min por conta do login silenciosamente:

• checkRateLimit (INCR) falha → cai no fallback em memória (memIncrement);
• mas peekRateLimit (GET) não é bloqueado pelo MISCONF (só escritas são recusadas) → lê do Redis vazio e retorna 0;
• resultado: o bloqueio por falhas (contaBloqueadaPorFalhas) nunca dispara — a 6ª tentativa contra a mesma conta passa reto, e o teste app/actions/auth/signInWithPassword.test.ts falha com expected 'invalid_credentials' to be 'rate_limited'.

Como reproduzir

1. Windows + Docker Desktop, repositório em unidade D: (HD externo ou partição não-C).
2. docker compose --env-file .env.local up -d (override sobe redis com bind ./data/redis).
3. docker exec deskcomm-redis redis-cli incr smoke:1 → MISCONF (escritas desabilitadas).
4. npx vitest run app/actions/auth/signInWithPassword.test.ts → 1 falha (rate_limited esperado, invalid_credentials recebido).
5. Log do app: [ai-dispatcher.rate-limit] redis incr failed; falling back to in-memory a cada tentativa.

Causa raiz

Docker Desktop no Windows tem uma limitação conhecida: bind mount de arquivos/diretórios em unidades que não são C: se comporta mal (arquivos viram diretório, diretórios ficam inacessíveis). O projeto já esbarrou nisso no Supabase local (supabase\.temp → junction NTFS para C:), mas o redis do override não tinha a mesma proteção.

Fix aplicado localmente (workaround, sem mudar o compose)

Junction NTFS data/redis → C:\Users\<user>\.qwen\redis-data\deskcommcrm (mesmo padrão já usado em supabase\.temp). Após isso: incr volta a funcionar, rdb_last_bgsave_status/aof_last_write_status → ok, e o teste passa verde.

Sugestão para o upstream

1. docs/threat-model.md (T2) documenta apenas o caso "Redis não configurado" (UPSTASH_REDIS_REST_URL ausente). Fica uma lacuna: "Redis configurado mas quebrado (MISCONF)" também anula o limite, e o teste unitário da fiação (signInWithPassword.test.ts) é o único que pega isso — e só falha em ambientes Windows com bind D: quebrado.
2. Considerar um healthcheck ou aviso mais explícito quando INCR falha por MISCONF (o warn atual é genérico e some após a primeira vez por processo).
3. No docker-compose.override.yml, documentar o quirk do Windows/Docker Desktop junto do volume do redis (ou apontar o bind para C:).

Ambiente

• Windows 11, Docker Desktop (WSL2), drive D: = HD externo.
• Supabase CLI 2.110.0; teste afetado: app/actions/auth/signInWithPassword.test.ts (issue Rate limit ausente em login, signup e aceite de convite #64).
• Nenhum impacto em produção/self-host (Linux): o docker-compose.prod.yml roda Redis efêmero (--appendonly no) e o MISCONF não ocorre.

[melgarafael]

Obrigado, @vagnerdearaujo — procede, e é mais grave do que o título sugere. Corrigido no PR #242.

O Windows não é a causa. O defeito é assimetria entre as duas trilhas do limitador, e qualquer disco cheio produz o mesmo estado — o Docker Desktop só foi o mensageiro:

• checkRateLimit (lib/ai/dispatcher/rate-limit.ts:128-136) cai para a memória quando a escrita falha;
• peekRateLimit (:155-171) só caía se a leitura própria lançasse.

Existe um estado em que o Redis recusa escrita e atende leitura — exatamente o MISCONF que você viu. Aí o incr cai para a memória, o get responde 200 com a chave ausente, e o peek devolvia 0 com o contador real vivo na memória.

O que morria é o teto por conta de lib/auth/rate-limit.ts — o único que barra força bruta distribuída por muitos IPs, e que o comentário do próprio arquivo declara "NÃO configurável" justamente por ser o último recurso. Ele parava de barrar sem exceção, sem log de erro e sem tela diferente. O "silenciosamente" do seu título é a parte mais importante do report.

Medido com a pilha real — nada de mock do limitador nem do Redis: @upstash/redis 1.38.2 → hiett/serverless-redis-http → redis:7-alpine forçado a MISCONF de verdade (--save 1 1, depois chmod 000 /data e bgsave), confirmado por rdb_last_bgsave_status:err:

$ curl -X POST .../ -d ["GET","alvo"]              -> HTTP 200 {"result":"1"}
$ curl -X POST .../ -d ["INCR","probe:contador"]   -> HTTP 400 {"error":"MISCONF ..."}

Duas fotos, uma variável trocada (o chmod do /data), 10 senhas erradas seguidas na mesma conta, teto 5:

MISCONF   bloqueios = [false x10]          nunca bloqueou
saudável  bloqueios = [false x5, true x5]  bloqueou na 6a

Um detalhe que só apareceu medindo, e que muda o entendimento do risco: com o Redis totalmente fora (conexão destruída) o teto já funcionava — as duas trilhas caem juntas para a memória e ele sobrevive por processo. O buraco era o estado parcial. Isso é contra-intuitivo e é justamente por isso que passou despercebido: quem testasse "derrubar o Redis" veria tudo funcionando.

O conserto é Math.max(contador do Redis, contador da memória) no peek — falhar fechado, contar o maior e nunca o menor. O arquivo de teste novo (lib/ai/dispatcher/rate-limit-misconf.test.ts) tem três casos, e o terceiro é o controle do caso "Redis fora": ele passava antes do conserto e existe para ninguém creditar ao commit uma proteção que já existia.

Sobre o docker-compose de dev que você mencionou: não mexi nele nesta rodada. O conserto acima faz o produto se defender independentemente do que o Redis de desenvolvimento faça, que era o risco de verdade. Se quiser abrir um PR ajustando a configuração de persistência do Redis de dev para o caso do Windows, é bem-vindo — mas agora é conforto, não segurança.