fix: added channel to handle concurrency bug

[fazledyn-or]

Description

This PR fixes a concurrency related bug in your codebase.

While triaging your project, our bug fixing tool generated the following message-

In file: loadTests.go, there is a function tryNewFramework which contains a send or a receive operation on a channel and there is no matching receive or send operation on that channel from another goroutine. The goroutine will be blocking on that channel operation. iCR identified the source of the possible blocking channel operation and suggested to avoid it.

In file loadTests.go, there's a method tryNewFramework that has a select statement that goes-

	select {
	case result := <-ch:
		ret = result
	case <-time.After(timeout):
		ret = nil
		err = fmt.Errorf("unable to create new framework for user %s within %v", username, timeout)
	}

In this select statement, there's a receive operation from channel ch along with a receive operation from a timeout channel. On the other hand, in the goroutine, there's a send operation to channel ch. If no receive operation is performed on ch channel within the timeout, then a time-out will take place. It all seems correct except for a corner case.

The receive on channel ch and the timeout may take place at the same moment. In that case, the select will randomly choose one of those two receives. From documentation-

If one or more of the communications can proceed, a single one that can proceed is chosen via a uniform pseudo-random selection. Otherwise, if there is a default case, that case is chosen. If there is no default case, the "select" statement blocks until at least one of the communications can proceed.

If, select chooses the timeout, then the go-routine that performs the send on channel ch will remain halted since the receiving end isn't ready.

Solution

As a solution, we introduce another channel called quit. In the sending go-routine, we create a select statement that reads from quit channel and performs the send on ch. And in the receiving end, when we get a timeout, we simply close the quit channel. If the channel is closed, the other go-routine will notice a closed channel and will exit normally.

Issue ticket number and link

None

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

This hasn't been tested.

Checklist:

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added meaningful description with JIRA/GitHub issue key(if applicable), for example HASSuiteDescribe("STONE-123456789 devfile source")
• I have updated labels (if needed)

Sponsorship and Support

This work is done by the security researchers from OpenRefactory and is supported by the Open Source Security Foundation (OpenSSF): Project Alpha-Omega. Alpha-Omega is a project partnering with open source software project maintainers to systematically find new, as-yet-undiscovered vulnerabilities in open source code - and get them fixed – to improve global software supply chain security.

The bug is found by running the Intelligent Code Repair (iCR) tool by OpenRefactory and then manually triaging the results.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign flacatus for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

Hi @fazledyn-or. Thanks for your PR.

I'm waiting for a redhat-appstudio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud