[matt-edmondson]

Fixes #39

What changed

SetKeepDisplayAwake read Request under gate, released the lock, and then took it again in SetRequest to write a modified copy. If another request change landed in that gap, it was overwritten, and StateChanged still fired for both calls. This is the request-path counterpart of #30. The fix has the same shape as #31: the decision is made inside the lock.

• New public overload SetRequest(Func<SleepBlockRequest, SleepBlockRequest> update). It runs update on the request in force under gate, then applies the result. Behaviour is otherwise unchanged: re-acquire when active, no event when nothing changed. A null result throws ArgumentNullException and leaves the request alone. Because the overload is public, it's a [minor] change. Callers get atomic partial edits such as SetRequest(current => current with { Reason = "Rendering" }).
• SetKeepDisplayAwake and SetRequest(SleepBlockRequest) now both go through it.
• The tool's --reason option used the same racy SetRequest(controller.Request with { … }) shape. It now uses the overload.
• The README API table lists the new overload.

Tests

• SetKeepDisplayAwake_RacingAReasonUpdate_KeepsBothChanges runs SetKeepDisplayAwake(true) against a reason-only update over 3000 trials. Each trial uses a fresh controller, and two long-lived threads are released together by spinning on shared counters. It asserts that every trial ends with both changes. Starting a task per trial (the Decide and apply a Toggle under one lock, so concurrent toggles each flip once [patch] #31 Toggle-test style) staggers the two sides too much: with that design the old code passed 200/200, so the test uses long-lived threads instead. The threads are background threads and every wait has a 10 s timeout, so a failure can't hang the test host.
• SetRequest_WithAnUpdate_AppliesItToTheRequestInForce and SetRequest_WithAnUpdateThatReturnsNull_ThrowsAndKeepsTheRequest cover the new overload directly.
• I put back the old SetKeepDisplayAwake body and kept everything else. The race test then failed on three runs out of three, losing a change in 8 to 13 of every 2000 trials (4 cores). With the fix, the full suite passes on repeated runs (32/32, about 6 s).

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
85.7% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud