Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

goroutineresourceleak: checkChannelLeak misses usage via function-call indirection (channel_usage_indirection_blind)

Abierto Apto para principiantes
  • ¿Algo no está bien?
#69,613 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
72/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
go
Área
devtools

Línea de trabajo

Lee pkg/linters/goroutineresourceleak/goroutineresourceleak.go, centrándote en checkChannelLeak y markChannelUsage; después, revisa los SAFE PATTERNS en testdata/src/a/a.go, alrededor de las líneas 259-318. Añade el caso de prueba descrito para una llamada a una función auxiliar y amplía el análisis de uso para que un canal pasado a una función auxiliar no se notifique como una fuga. El trabajo estará terminado cuando pase el nuevo caso y los casos positivos y negativos existentes enumerados conserven su comportamiento.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

cookie sergo
Problem

pkg/linters/goroutineresourceleak/goroutineresourceleak.go checkChannelLeak (lines 149-171), backed by createdChannels and markChannelUsage (lines 173-236), only recognizes a channel as used inside a spawned goroutine via three direct AST shapes within the goroutine body itself: a SendStmt (ch <- v), a literal close(ch) call, or a unary receive (<-ch). There is no handling for a channel being passed as an argument to another function call, stored into a struct field or closure, or returned -- all common decomposition patterns where the real send/receive/close happens inside the callee rather than inline in the goroutine body.

This causes a false-positive channel leak report on perfectly safe code: a goroutine that creates a channel and immediately hands it off to a well-behaved helper function (for example go func() { ch := make(chan int); process(ch) }(), where process does the actual send/receive/close) has zero recognized usage events under the current scan, so it falls through every safe-pattern check in checkChannelLeak and gets flagged as a leak.

Evidence
  • goroutineresourceleak.go:159-160 -- channels := createdChannels(pass, body); markChannelUsage(pass, body, channels), both walk only the goroutine's own body via ast.Inspect (excluding FuncLit boundaries)
  • goroutineresourceleak.go:208-233 -- markChannelUsage checks only *ast.SendStmt, a close(...) CallExpr, and a token.ARROW UnaryExpr; no case handles a channel identifier appearing as a plain CallExpr argument, a composite literal field, or a return value
  • testdata/src/a/a.go:259-318 (SAFE PATTERNS section) has zero coverage for a channel passed to a helper function -- every existing safe case either uses one of the three recognized syntactic forms directly inline, or is a named-function goroutine (go doSomeWork()), which is explicitly out of scope for the whole check per the namedFunctionGoroutine comment
  • This is distinct from the already-filed paren_unwrap_gap (#68591) and adjacent_defer_assumption (#68945) issues on this same linter, which affect checkCancelLeak/checkMutexLeak rather than checkChannelLeak
Recommendation

Extend markChannelUsage to also treat a channel identifier appearing as a CallExpr argument (or in a composite literal / return statement) as a usage event, at least conservatively marking it as both sent-and-received to suppress the diagnostic -- a full call-graph analysis is out of scope for an AST-heuristic linter, but a channel handed to any opaque call should not be treated as provably unused.

Validation checklist
  • Add a testdata case: ch := make(chan int); process(ch) where process is an external/unanalyzed function -- should NOT be flagged
  • Confirm existing positive cases (channelWithoutUse, channelWithSend, channelWithReceive, channelWithUnbufferedSequentialSendAndReceive) still correctly flag
  • Confirm existing negative cases (channelWithClose, channelWithBufferedSendAndReceive) still correctly pass
Effort

Small -- one function (markChannelUsage) plus one new testdata fixture.

Pattern class: channel_usage_indirection_blind (new -- a resource-usage scan recognizing only a closed set of direct syntactic forms, with no awareness of usage via a function-call indirection).

Generated by 🤖 Sergo - Serena Go Expert · claude · agent · 211.8 AIC · ⌖ 0.49 AIC · ⊞ 5.3K · ◷

  • expires on Oct 23, 2026, 7:59 PM UTC-08:00
Lenguaje dominante
Go
Estrellas
5.4k
Forks
584
Merge medio
3 h 20 min
PR fusionados (30 d)
830

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de github/gh-aw

Todos los issues de github/gh-aw

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.