53 lines
2.7 KiB
Gherkin
53 lines
2.7 KiB
Gherkin
@tdd_issue @tdd_issue_10512
|
|
Feature: MCPToolAdapter releases RLock during transport calls
|
|
As a developer using MCPToolAdapter concurrently
|
|
I want the adapter to release its RLock before making transport calls
|
|
So that concurrent operations are not blocked by slow transport calls
|
|
|
|
# -------------------------------------------------------------------
|
|
# Bug #10512: MCPToolAdapter holds RLock during entire transport call,
|
|
# blocking concurrent operations.
|
|
#
|
|
# The fix releases the lock before the transport.call() and
|
|
# re-acquires it only when shared state must be mutated.
|
|
# -------------------------------------------------------------------
|
|
|
|
Scenario: Concurrent invoke calls are not blocked by a slow transport
|
|
Given a connected MCP adapter with a concurrency-tracking transport tool "slow_op" taking 0.05 seconds
|
|
When I invoke "slow_op" concurrently from 3 threads
|
|
Then all 3 concurrent invocations should succeed
|
|
And at least 2 invocations should have been in-flight simultaneously
|
|
|
|
Scenario: Concurrent discover_tools calls are not blocked by a slow transport
|
|
Given a connected MCP adapter with a concurrency-tracking discovery transport taking 0.05 seconds
|
|
When I call discover_tools concurrently from 3 threads
|
|
Then all 3 concurrent discoveries should succeed
|
|
And at least 2 discoveries should have been in-flight simultaneously
|
|
|
|
Scenario: Lock is not held during invoke transport call
|
|
Given a connected MCP adapter with a lock-checking transport tool "check_lock"
|
|
When I invoke "check_lock" with arguments {}
|
|
Then the invocation should succeed
|
|
And the lock should not have been held during the transport call
|
|
|
|
Scenario: Lock is not held during discover_tools transport call
|
|
Given a connected MCP adapter with a lock-checking discovery transport
|
|
When I discover tools from the adapter
|
|
Then the lock should not have been held during the discovery transport call
|
|
|
|
Scenario: Invoke still validates under lock before transport call
|
|
Given a connected MCP adapter with a slow transport tool "slow_op" taking 0.1 seconds
|
|
When I invoke "nonexistent_tool" with arguments {}
|
|
Then the invocation should fail
|
|
And the invocation error should mention "not found"
|
|
|
|
Scenario: Invoke on disconnected adapter still raises under lock
|
|
Given an MCP adapter with a mock transport
|
|
When I invoke MCP tool "any_tool" while disconnected
|
|
Then the adapter error should mention "not connected"
|
|
|
|
Scenario: Discover on disconnected adapter still raises under lock
|
|
Given an MCP adapter with a mock transport
|
|
When I discover tools expecting an error
|
|
Then the adapter error should mention "not connected"
|