HAL9000
40137f4f2a
The PR contained duplicate step definitions and feature files that caused
behave AmbiguousStep errors crashing the unit_tests gate. The underlying
thread-safety fix for get_provider_registry() already landed on master in
commit e1cd306f6, so the scenario now passes as a regression test.
- Delete scripts/fix_registry_steps_tmp.py: temporary debugging script with
hardcoded /tmp paths that produced 6 ruff errors (F401, UP015, E501 x4).
- Delete features/tdd_registry_thread_safety.feature and
features/steps/tdd_registry_thread_safety_steps.py: weaker duplicates of
the canonical files under features/providers/ and features/steps/. Their
step decorators collided with the elaborate barrier-based steps in
registry_thread_safety_steps.py, causing AmbiguousStep across the suite.
- Remove @tdd_expected_fail tag from the canonical scenario per the
CONTRIBUTING.md bug fix workflow: behave's TDD harness explicitly
instructs removing the tag once the bug appears fixed, so the scenario
now functions as a normal regression test.
- Apply ruff format to features/steps/registry_thread_safety_steps.py.
ISSUES CLOSED: #10409
21 lines
1.1 KiB
Gherkin
21 lines
1.1 KiB
Gherkin
@tdd_issue @tdd_issue_10409
|
|
Feature: TDD Issue #10409 — Non-thread-safe singleton in get_provider_registry()
|
|
The function get_provider_registry() in cleveragents.providers.registry
|
|
implements a singleton pattern without thread-safety guards. Under concurrent
|
|
access, two threads can each observe _registry is None before either has
|
|
finished constructing the ProviderRegistry, causing both to independently
|
|
instantiate a new registry. This violates the singleton contract and can lead
|
|
to inconsistent provider state across the application.
|
|
|
|
This TDD issue captures the failing Behave scenario that proves the race
|
|
condition exists. It must be merged to master BEFORE the corresponding bug
|
|
fix issue is worked on.
|
|
|
|
See CONTRIBUTING.md > Bug Fix Workflow > TDD Issue Test Tags.
|
|
|
|
Scenario: Concurrent calls to get_provider_registry return the same instance
|
|
Given the global provider registry has been reset
|
|
When two threads call get_provider_registry() simultaneously
|
|
Then both threads should receive the identical registry instance
|
|
And only one ProviderRegistry should have been constructed
|