Files
temp/features/tdd_automation_profile_session_leak.feature
Luis Mendes 9e93ea5fc6 fix(persistence): close session in AutomationProfileRepository auto_commit finally block
Add missing `finally: if self._auto_commit: session.close()` blocks to
all four public session-creating methods in `AutomationProfileRepository`:
`get_by_name()`, `list_all()`, `upsert()`, and `delete()`.  Without
these blocks, sessions were never closed when the repository operated in
auto_commit mode, causing a slow session leak that could exhaust the
connection pool over time.

The fix mirrors the pattern already used by `SessionRepository`, which
correctly closes its session in a `finally` block for every public method.

Removed the `@tdd_expected_fail` tag from the TDD test
(`tdd_automation_profile_session_leak.feature`) so the six scenarios
now run as normal regression tests (four original plus two new scenarios
for `get_by_name` and `list_all`).

ISSUES CLOSED: #987
2026-04-03 19:00:22 +00:00

59 lines
3.2 KiB
Gherkin

@tdd_issue @tdd_issue_987
Feature: TDD Bug #987 — AutomationProfileRepository session leak
As a developer
I want to verify that AutomationProfileRepository closes sessions
in auto_commit mode
So that regressions in session cleanup are caught
Regression guard for bug #987. AutomationProfileRepository methods
previously committed when auto_commit was True but never called
session.close() in a finally block. The fix added
``finally: if self._auto_commit: session.close()`` to all public
session-creating methods (get_by_name, list_all, upsert, delete),
matching the pattern already used by SessionRepository.
These scenarios verify that sessions are properly closed in
auto_commit mode for both success and error paths across all
public methods.
Scenario: upsert closes session in auto_commit mode on success
Given an AutomationProfileRepository with auto_commit enabled and a tracking session factory
When I upsert a valid automation profile via the repository
Then the tracking session should have been closed
Scenario: delete closes session in auto_commit mode on success
Given an AutomationProfileRepository with auto_commit enabled and a tracking session factory
And a persisted automation profile named "local/leak-test-profile"
When I delete the automation profile "local/leak-test-profile" via the repository
Then the tracking session should have been closed
Scenario: upsert closes session in auto_commit mode on database error
Given an AutomationProfileRepository with auto_commit enabled and a failing session factory
When I attempt to upsert a profile that triggers a database error
Then the tracking session should have been closed despite the error
Scenario: delete closes session in auto_commit mode on database error
Given an AutomationProfileRepository with auto_commit enabled, a pre-populated profile, and a failing-flush tracking session
When I attempt to delete a profile that triggers a database error
Then the tracking session should have been closed despite the delete error
Scenario: get_by_name closes session in auto_commit mode on success
Given an AutomationProfileRepository with auto_commit enabled and a tracking session factory
When I look up a profile by name via the repository
Then the tracking session should have been closed
Scenario: list_all closes session in auto_commit mode on success
Given an AutomationProfileRepository with auto_commit enabled and a tracking session factory
When I list all profiles via the repository
Then the tracking session should have been closed
Scenario: get_by_name closes session in auto_commit mode on database error
Given an AutomationProfileRepository with auto_commit enabled and a failing-query session factory
When I attempt to look up a profile that triggers a database error
Then the tracking session should have been closed despite the get_by_name error
Scenario: list_all closes session in auto_commit mode on database error
Given an AutomationProfileRepository with auto_commit enabled and a failing-query session factory
When I attempt to list profiles that triggers a database error
Then the tracking session should have been closed despite the list_all error