fix(zwave_js): make UC v1 post-write verify failures non-fatal (#1251)#1255
Conversation
The post-set/clear verification GET that forces V1 locks' value cache to refresh was raising LockDisconnected on any Z-Wave error, which on Schlage UC v1 locks with flaky interviews (the canonical #1251 case) turned every credential write into a slot-suspension feedback loop: the SET ack'd at the wire, the verify GET timed out the same way the interview did, and the whole operation reported failure -- the sync manager then retried, hit the same timeout, and eventually disabled the slot. Log the verify timeout and continue: the SET/CLEAR already ack'd and the caller's `_push_credential_update` delivers the truth to the coordinator immediately afterward, so the optimistic push is the safety net. The hourly hard-refresh backstop reconciles any genuine cache drift. Non-Z-Wave exceptions (programming bugs) still propagate. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Entire-Checkpoint: 49038c7ae9a3
There was a problem hiding this comment.
Pull request overview
This PR adjusts the Z-Wave JS User Code CC v1 fallback behavior so that post-write verification GET failures (transport/server errors) no longer fail an otherwise-acknowledged PIN set/clear operation, preventing retry loops and slot suspension on flaky UC v1 locks (issue #1251).
Changes:
- Make UC v1 post-write verification poll failures non-fatal by logging a warning and continuing on
BaseZwaveJSServerError. - Update/replace UC fallback tests to assert the new “warn and continue” behavior for set/clear and to ensure non-Z-Wave exceptions still propagate.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| custom_components/lock_code_manager/providers/_zwave_js_uc.py | Softens UC v1 post-write verification failures from raising LockDisconnected to emitting a warning and proceeding. |
| tests/providers/zwave_js/test_uc_fallback.py | Replaces the prior “verify failure raises” test with new coverage for warning-and-continue on set/clear, plus propagation for non-Z-Wave errors. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
The verify-failure path fires on every write to an affected lock; the per-lock fallback activation already emits a one-shot WARNING that flags the underlying #1251 pathology, so the per-write follow-on should not escalate to WARNING and spam the log. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Entire-Checkpoint: 793557c7d881
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1255 +/- ##
=======================================
Coverage 97.11% 97.11%
=======================================
Files 54 54
Lines 6411 6411
Branches 461 461
=======================================
Hits 6226 6226
Misses 185 185
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
Proposed change
Soften the User Code CC v1 post-write verification poll in the issue-#1251 fallback layer: log a warning and continue on Z-Wave wire errors instead of raising `LockDisconnected`.
The poll exists to force-update the value cache after a SET/CLEAR on V1 locks (which don't reliably push the new value back themselves). On Schlage UC v1 locks with flaky interviews -- the canonical #1251 population -- the verify GET hits the same timeout the interview did, so every credential write went:
That's the "code slots won't stay enabled" symptom TheMegamind reported on #1251 against 4.0.3.
The optimistic `_push_credential_update` runs immediately after the verify, so the coordinator already has the post-write state regardless of whether the GET succeeded. The hourly hard-refresh backstop reconciles any genuine cache drift later. Trading "we couldn't refresh the cache right now" for "the slot survives" matches the safer outcome for a flaky lock.
Non-Z-Wave exceptions (programming bugs) still propagate -- the softening only covers `BaseZwaveJSServerError`.
Type of change
Additional information
Checklist
Tests:
🤖 Generated with Claude Code