# This test captures bug #10438 — McpClient.start() race condition.
#
# The @tdd_expected_fail tag inverts the test result: the underlying assertion
# fails (proving the bug exists) but CI reports the scenario as passed.
# When #10438 is fixed, the @tdd_expected_fail tag must be removed.
#
# See: https://git.cleverthis.com/cleveragents/cleveragents-core/issues/10438

@tdd_issue @tdd_issue_10438
Feature: TDD Issue #10438 — McpClient.start() race condition allows concurrent double initialization
  McpClient.start() releases the threading.RLock after setting _state to STARTING
  but before calling connect() and discover_tools().  If two threads call start()
  concurrently, both can pass the _started idempotency check (which is still False)
  and both proceed to call connect() and discover_tools() simultaneously.

  This test proves the race exists by launching multiple threads that call start()
  simultaneously via a threading.Barrier and verifying that connect() is called
  exactly once (the correct, thread-safe behavior).  Without the bug present,
  connect() is called exactly once.  With the bug, connect() is called multiple times.

  Scenario: Concurrent start() calls must invoke connect() exactly once
    Given an McpClient with a counting mock transport
    When 5 threads call start() concurrently through a barrier
    Then connect() should have been called exactly once
    And discover_tools() should have been called exactly once
    And the client state should be "running"
    And all 5 threads should have completed without hanging
