SonarSource Rules
  • Products

    In-IDE

    Code Quality and Security in your IDE with SonarQube Ide

    IDE extension that lets you fix coding issues before they exist!

    Discover SonarQube for IDE

    SaaS

    Code Quality and Security in the cloud with SonarQube Cloud

    Setup is effortless and analysis is automatic for most languages

    Discover SonarQube Cloud

    Self-Hosted

    Code Quality and Security Self-Hosted with SonarQube Server

    Fast, accurate analysis; enterprise scalability

    Discover SonarQube Server
  • SecretsSecrets
  • ABAPABAP
  • AnsibleAnsible
  • ApexApex
  • AzureResourceManagerAzureResourceManager
  • CC
  • C#C#
  • C++C++
  • CloudFormationCloudFormation
  • COBOLCOBOL
  • CSSCSS
  • DartDart
  • DockerDocker
  • FlexFlex
  • GitHub ActionsGitHub Actions
  • GoGo
  • HTMLHTML
  • JavaJava
  • JavaScriptJavaScript
  • JSONJSON
  • JCLJCL
  • KotlinKotlin
  • KubernetesKubernetes
  • Objective CObjective C
  • PHPPHP
  • PL/IPL/I
  • PL/SQLPL/SQL
  • PythonPython
  • RPGRPG
  • RubyRuby
  • RustRust
  • ScalaScala
  • ShellShell
  • SwiftSwift
  • TerraformTerraform
  • TextText
  • TypeScriptTypeScript
  • T-SQLT-SQL
  • VB.NETVB.NET
  • VB6VB6
  • XMLXML
  • YAMLYAML
Go

Go static code analysis

Unique rules to find Bugs, Vulnerabilities, Security Hotspots, and Code Smells in your GO code

  • All rules 94
  • Vulnerability21
  • Bug13
  • Security Hotspot14
  • Code Smell46
Filtered: 1 rule found
testing
    Impact
      Clean code attribute
        1. Test functions should not call "t.Fatal" from separate goroutines

           Bug

        Test functions should not call "t.Fatal" from separate goroutines

        intentionality - logical
        reliability
        maintainability
        Bug
        • testing
        • concurrency

        This rule raises an issue when test functions call t.Fatal, t.FailNow, t.Fatalf, t.Skip, t.Skipf, or t.SkipNow from goroutines other than the main test goroutine.

        Why is this an issue?

        How can I fix it?

        More Info

        In Go testing, functions like t.Fatal and t.FailNow call runtime.Goexit() to immediately terminate the current goroutine and mark the test as failed. However, when these functions are called from a goroutine other than the main test goroutine, they only terminate that specific goroutine, not the entire test.

        This creates several problems:

        • The test may continue running even after a failure is detected, leading to unpredictable behavior
        • Other goroutines may continue executing, potentially causing resource leaks or interfering with subsequent tests
        • The test may hang indefinitely if the main goroutine is waiting for the failed goroutine to complete
        • Error reporting becomes unclear since the test doesn’t immediately fail when the issue is detected

        The Go testing package is designed with the assumption that test control functions are called from the main test goroutine. When this assumption is violated, the testing framework cannot properly manage the test lifecycle.

        What is the potential impact?

        Calling t.Fatal from separate goroutines can cause tests to hang indefinitely, produce unreliable results, or mask real failures. This leads to flaky tests that are difficult to debug and can block continuous integration pipelines. In severe cases, hanging tests may consume system resources and require manual intervention to terminate.

          Available In:
        • SonarQube CloudDetect issues in your GitHub, Azure DevOps Services, Bitbucket Cloud, GitLab repositories

        © 2025 SonarSource Sàrl. All rights reserved.

        Privacy Policy | Cookie Policy | Terms of Use