refactor(lock): extract helpers from _acquire_fd to reduce complexity (S3776) #60

Open
Claude wants to merge 1 commit from Claude/backup-script:fix/issue-2-S3776-lock-acquire-fd-complexity into master
First-time contributor

Closes #2

_acquire_fd had cognitive complexity 17 (SonarQube ceiling: 15).

Refactor

Split the polling loop into three named helpers:

Helper Job
_try_lock_now(fd) One non-blocking acquisition attempt; returns bool
_holder_is_stale() Has the recorded PID died on us?
_still_waiting(start, timeout) Deadline check

Behavior

Identical. Same single probe-on-first-block, same 0.5s poll interval, same
LockHeld on timeout. Both _try_lock_now and _acquire_fd still treat
EWOULDBLOCK and other OSErrors the same — that broader catch was already
the master behavior (separate PR #44 deals with the redundant tuple form).

Verification

  • pytest -q tests/unit/test_lock.py tests/unit/test_lock_stale_pid.py tests/unit/test_app_lock_wait.py — 18 passed
  • mypy --strict src/gardien/core/lock.py — passes
Closes #2 `_acquire_fd` had cognitive complexity 17 (SonarQube ceiling: 15). ### Refactor Split the polling loop into three named helpers: | Helper | Job | |---|---| | `_try_lock_now(fd)` | One non-blocking acquisition attempt; returns bool | | `_holder_is_stale()` | Has the recorded PID died on us? | | `_still_waiting(start, timeout)` | Deadline check | ### Behavior Identical. Same single probe-on-first-block, same 0.5s poll interval, same `LockHeld` on timeout. Both `_try_lock_now` and `_acquire_fd` still treat EWOULDBLOCK and other OSErrors the same — that broader catch was already the master behavior (separate PR #44 deals with the redundant tuple form). ### Verification - `pytest -q tests/unit/test_lock.py tests/unit/test_lock_stale_pid.py tests/unit/test_app_lock_wait.py` — 18 passed - `mypy --strict src/gardien/core/lock.py` — passes
Split the polling loop into three single-purpose helpers:
  _try_lock_now(fd)     — one non-blocking acquisition attempt
  _holder_is_stale()    — has the recorded PID died on us?
  _still_waiting(...)   — deadline check

Behavior is unchanged: same probe-once semantics, same 0.5s poll, same
LockHeld on timeout. Cognitive complexity of _acquire_fd drops from 17
to ~6, comfortably under SonarQube's 15-line ceiling.

Refs bc1bb/backup-script#2
This pull request can be merged automatically.
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u fix/issue-2-S3776-lock-acquire-fd-complexity:Claude-fix/issue-2-S3776-lock-acquire-fd-complexity
git switch Claude-fix/issue-2-S3776-lock-acquire-fd-complexity

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch master
git merge --no-ff Claude-fix/issue-2-S3776-lock-acquire-fd-complexity
git switch Claude-fix/issue-2-S3776-lock-acquire-fd-complexity
git rebase master
git switch master
git merge --ff-only Claude-fix/issue-2-S3776-lock-acquire-fd-complexity
git switch Claude-fix/issue-2-S3776-lock-acquire-fd-complexity
git rebase master
git switch master
git merge --no-ff Claude-fix/issue-2-S3776-lock-acquire-fd-complexity
git switch master
git merge --squash Claude-fix/issue-2-S3776-lock-acquire-fd-complexity
git switch master
git merge --ff-only Claude-fix/issue-2-S3776-lock-acquire-fd-complexity
git switch master
git merge Claude-fix/issue-2-S3776-lock-acquire-fd-complexity
git push origin master
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
bc1bb/backup-script!60
No description provided.