zwave-js / zwave-js-ui / 19434312419

20%

push

github

fix: defer firmware update check until after re-interview completes (#4462)

Fix race condition between firmware update check and device interview

## Plan
- [x] Track nodes that are being re-interviewed after firmware updates
- [x] Remove immediate firmware update check after firmware update
finishes (when reInterview is true)
- [x] Add firmware update check in interview completion handler (when
interview was triggered by firmware update)
- [x] Ensure firmware update check still happens immediately when
reInterview is false
- [x] Run linting and tests to validate changes
- [x] Run CodeQL security scan
- [x] Verify logic for all scenarios and edge cases
- [x] Refactor to use private Set instead of node property
- [x] Add cleanup on interview failure and client close

## Problem
When a device firmware update completes and triggers a re-interview, the
firmware update check runs immediately with the cached old firmware
version. Then the interview updates the firmware version, but the check
has already completed with stale data, showing incorrect "firmware
update available" notifications.

## Solution
- Uses a private `Set<number>` (`_nodesPendingFirmwareUpdateCheck`) in
ZwaveClient to track node IDs pending firmware update checks
- Modified `_onNodeFirmwareUpdateFinished` to:
- Add node ID to Set when `result.reInterview` is true (deferring the
check until interview completes)
- Perform immediate check when `result.reInterview` is false
(maintaining existing behavior)
- Modified `_onNodeInterviewCompleted` to check for firmware updates
when node ID is in the Set, ensuring the check uses the updated firmware
version
- Added cleanup in `_onNodeInterviewFailed` to remove node IDs from Set
when interview fails (prevents memory leak)
- Added cleanup in `close()` method to clear the Set when client is
closed (prevents stale state)

## Benefits
- Cleaner separation of concerns (node data vs. internal state tracking)
- More efficient memory usage (Set vs. proper... (continued)

333 of 441 branches covered (75.51%)

Branch coverage included in aggregate %.

0 of 43 new or added lines in 1 file covered. (0.0%)

4048 of 21416 relevant lines covered (18.9%)

1.18 hits per line