test-versioning: install-race
	@echo "Running minio versioning tests"
	@env bash $(PWD)/docs/bucket/versioning/versioning-tests.sh

test-configfile: install-race
	@env bash $(PWD)/docs/distributed/distributed-from-config-file.sh

test-upgrade: install-race
	@echo "Running minio upgrade tests"
	@(env bash $(PWD)/buildscripts/minio-upgrade.sh)

test-race: verifiers build ## builds minio, runs linters, tests (race)

This property is sometimes referred to as DRF-SC: data-race-free programs
execute in a sequentially consistent manner.
</p>

<p>
While programmers should write Go programs without data races,
there are limitations to what a Go implementation can do in response to a data race.
An implementation may always react to a data race by reporting the race and terminating the program.

import org.junit.jupiter.api.Test;
import org.mockito.Mockito;

import jcifs.CIFSContext;
import jcifs.Configuration;
import jcifs.Credentials;

/**
 * Security-focused test cases for SmbSessionImpl to verify race condition fixes.
 */
public class SmbSessionImplSecurityTest {

    private CIFSContext mockContext;
    private SmbTransportImpl mockTransport;
    private Configuration mockConfig;

      "plan 1 TLS connected",
    )

    taskFaker.assertNoMoreTasks()
  }

  /**
   * This test performs two races:
   *
   *  * The first race is between plan0 and plan1, with a 250 ms head start for plan0.
   *  * The second race is between plan2 and plan3, with a 250 ms head start for plan2.
   *
   * We get plan0 and plan1 from the route planner.

  /**
   * This test is for a case where two Service.Listener callbacks for the same service would call
   * transitionService in the wrong order due to a race. Due to the fact that it is a race this test
   * isn't guaranteed to expose the issue, but it is at least likely to become flaky if the race
   * sneaks back in, and in this case flaky means something is definitely wrong.
   *

  internal val connectionSpecIndex: Int,
  internal val isTlsFallback: Boolean,
) : RoutePlanner.Plan,
  ExchangeCodec.Carrier {
  /** True if this connect was canceled; typically because it lost a race. */
  @Volatile private var canceled = false

  // These properties are initialized by connect() and never reassigned.

  /** The low-level TCP socket. */
  private var rawSocket: JavaNetSocket? = null

  /**

   * - Both request discover no existing connection. They both make a connection.
   * - The first request "wins the race".
   * - The second request discovers it "lost the race" and closes the connection it just opened.
   * - The second request uses the coalesced connection from request1.
   * - The coalesced connection is violently closed after servicing the first request.

    testClient?.let {
      val connectionPool = it.connectionPool

      connectionPool.evictAll()
      if (connectionPool.connectionCount() > 0) {
        // Minimise test flakiness due to possible race conditions with connections closing.
        // Some number of tests will report here, but not fail due to this delay.
        println("Delaying to avoid flakes")
        Thread.sleep(500L)

 *  Fix: Don't lose HTTP/2 flow control bytes when incoming data races with a stream close. If this
    happened enough then eventually the connection would stall.

 *  Fix: Acknowledge and apply inbound HTTP/2 settings atomically. Previously we had a race where we
    could use new flow control capacity before acknowledging it, causing strict HTTP/2 servers to
    fail the call.

    the previous alpha due to an unexpected race.


## Version 5.0.0-alpha.5

_2022-02-21_

 *  Fix: Don't include [Assertk][assertk] in OkHttp's production dependencies. This regression was
    introduced in the 5.0.0-alpha.4 release.
 *  Fix: Don't ask `Dns` implementations to resolve strings that are already IP addresses.
 *  Fix: Change fast fallback to race TCP handshakes only. To avoid wasted work, OkHttp will not