Three CI gates were failing on this PR; this commit addresses the root
causes for each:
* lint (ruff format): drop the blank line between the docstring close
and first statement in step_pr_create_with_error, and add the missing
second blank line between step_pr_check_remove_link_persisted and the
"Data integrity BDD step extensions" section comment block.
* unit_tests: two scenarios were inverted by `@tdd_expected_fail` on
post-fix assertions, masking unrelated test-logic problems.
- Remove `@tdd_expected_fail` from both `@tdd_issue_8179` scenarios in
project_repository.feature - they describe post-fix behaviour and
must report PASS as PASS, not as inverted-FAIL.
- Drop the "Given project exists" precondition from the Update-non-
existent scenario; the Background already initialises the in-memory
DB and creating the same project being "updated as non-existent" is
self-contradictory (caused the prior scenario to silently report
inverted-PASS while actually never raising).
- Update the OperationalError scenario in database_repository_coverage
to assert the post-fix invariant: the repository no longer calls
session.rollback() itself; that responsibility is delegated to the
outer UnitOfWork. Step text + assertion both flipped.
ISSUES CLOSED: #8179
Removed unconditional session.rollback() calls within exception handlers in:
- ProjectRepository.create()
- NamespacedProjectRepository.create() (IntegrityError handler)
- NamespacedProjectRepository.create() (OperationalError handler)
- NamespacedProjectRepository.update()
- NamespacedProjectRepository.delete()
The Unit of Work pattern already handles transaction rollback at the outer layer
via its except Exception: session.rollback() handler, making these inner rollbacks
redundant. SQLAlchemy automatically invalidates the transaction state when exceptions
occur after flush(), preventing partial data from being committed.
Removing the redundant rollbacks improves clarity, eliminates potential issues related
to exception chaining across retry boundary layers, and aligns repository implementations
with explicit transaction boundaries.
ISSUES CLOSED: #8179