Skip to content

New linter: blocking inside go #2802

@walber-araujo

Description

@walber-araujo

To upvote this issue, give it a thumbs up. See this list for the most upvoted issues.

  • I have read the Clojure etiquette and will respect it when communicating on this platform.

Is your feature request related to a problem? Please describe.

When working with clojure.core.async, it is easy to accidentally introduce blocking operations such as <!! or >!! inside a go block. Since go blocks are intended for non-blocking, cooperative concurrency and run on a limited thread pool, this mistake can lead to thread starvation, deadlocks, and performance issues.

This smell is critical because it breaks the non-blocking model of clojure.core.async, often causing deadlocks and thread starvation. Its relevance was confirmed in a guild session, with strong validation from 28 developers, including Clojure maintainers.

Describe the solution you'd like

I would like clj-kondo to provide a linting rule that detects the usage of blocking operations (e.g., <!!, >!!, or other blocking I/O) inside go blocks.

The linter could:

  • Identify go blocks (clojure.core.async/go)
  • Warn when blocking calls like <!! or >!! are used within them
  • Optionally suggest using non-blocking alternatives

This would help developers avoid common pitfalls when using core.async and improve code correctness and performance.

Describe alternatives you've considered

One alternative would be implementing this linter at the clojure-lsp, but since this a mostly syntactic pattern, clj-kondo is a better fit due to its fast static analysis.

Additional context
This smell is part of a catalog of 34 others (https://github.com/nufuturo-ufcg/clj-smells-catalog), built by mining GitHub repositories, blogs, and community resources from the Clojure ecosystem. The catalog was validated by the community through 140 survey responses, discussions at Clojure South 2025, and a guild session with 61 experienced Clojure developers, including the language’s lead maintainer.

We are already implementing this, including tests for the scenario, and would be happy to open a PR with the proposed solution

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions