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

relay: `Account::refusal()`'s wildcard would swallow a third refusal cause

Aberta Para iniciantes
#993 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
2/5
Tempo estimado
1-3 horas
Facilidade para iniciantes
68/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
rust
Domínio
backend

Direção de pesquisa

Comece em crates/nostream-relay/src/sink.rs:163-169 e inspecione as variantes de Refusal e os matchings exaustivos em refuse() e close_refused(). Em seguida, verifique os leitores em relay.rs:391 e subscribe.rs:283-287 para ver como cada resultado de recusa é tratado. O trabalho estará concluído quando Account::refusal() não tiver um caso genérico e o compilador exigir que cada leitor trate todas as variantes.

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

Descrição

factory rewrite rust

Account::refusal() (crates/nostream-relay/src/sink.rs:163-169) ends in _ => None, and Refusal has exactly two variants today, so the arm is unreachable. The problem is what happens when a third cause arrives:

  • Refusal gains a variant → refuse() and close_refused() are compiler-forced to handle it (they match exhaustively);
  • Account::refusal() is not — _ => None swallows it silently, and now two readers take that answer as "nothing to do":
    • relay.rs:391, the connection loop's top-of-iteration check, so the socket is never closed for the new cause;
    • subscribe.rs:283-287, the read's refusal guard, so the read neither stops nor parks and keeps encoding-and-discarding at the cost measured in #959 (≈450× a latched send).

So the next refusal cause added to this module would be half implemented in a way no test catches: a compile-clean, silently wrong socket.

What it needs

Replace the wildcard with an exhaustive match over Refusal so the compiler forces every reader to decide. If a None case must exist for a state that is genuinely "no refusal", model it as a third variant (None/Clear) rather than as a catch-all — that is the difference between the compiler asking and the reader remembering.

Found by the architecture lens in #959's review; left out of that PR because it is latent and the PR was already bounding two things. No behaviour changes today.

Linguagem predominante
TypeScript
Estrelas
829
Forks
234
Merge médio
17h 6min
PRs com merge (30d)
92

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.