WIP: Hue lan integration tests - #3177
Conversation
|
Invitation URL: |
|
philips-hue_coverage.xml
Minimum allowed coverage is Generated by 🐒 cobertura-action against c3893ff |
Test Results 73 files 552 suites 0s ⏱️ For more details on these errors, see this check. Results for commit c3893ff. ♻️ This comment has been updated with latest results. |
| ) | ||
| return | ||
| end | ||
| cosock.socket.sleep(backoff()) |
There was a problem hiding this comment.
not sure I agree with this change. I'll have to investigate further
There was a problem hiding this comment.
The max attempts could potentially be problematic because we only queue scans on connect or device adds so we might end up with no group information. I think the backoff is fine and might actually prevent a hot loop if the api calls don't end up yielding for some reason.
| ) | ||
| ) | ||
| else | ||
| cosock.socket.sleep(backoff()) |
There was a problem hiding this comment.
Same feeling here, the backoff is probably good but not getting the connectivity of the devices could leave some offline until the we reconnect sse or until the device connectivity changes and results in new sse event. This happens in a spawned cosock task so probably no harm in continuing to keep trying.
| -- without needing to mock rooms/zones REST responses or race the scan's own 45-second debounce | ||
| -- timing against whatever else a test is asserting on the same connection. Defaults to true; | ||
| -- production code never touches this. | ||
| grouped_utils.scanning_enabled = true |
There was a problem hiding this comment.
I think its fine but I think ideally the mock bridge server would be able to be configured to default respond to these requests with an empty valid response.
dkjson.decode returns (value, next_position, error_message), but process_rest_response propagated all of pcall's captured return values after decoding, not just the decoded value its own doc comment promises. That means the parse position (e.g. 74 for a 73-byte body) gets returned in the position every caller treats as `err`, so every successful REST call with a JSON body logs a spurious "Error performing <action>: <parse position>". Found via the first integration test to exercise a real, successful JSON-decoded REST response through this path. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> philips-hue: fix onmessage misreading json.decode's position as an error table.pack(pcall(json.decode, msg.data)) followed by table.remove(...,1) to strip the pcall success flag left `events, err = table.unpack(...)` capturing dkjson's second return value (the position it stopped scanning at, a non-nil number even on success) into `err` instead of its real third return value. Every SSE message was therefore logged as a JSON parse error and dropped without ever reaching the update/add/delete handling below -- there was no prior test coverage of this path to catch it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
1cf2f31 to
38ce6b0
Compare
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
38ce6b0 to
c3893ff
Compare
2 participants
Check all that apply
Type of Change
Checklist
Description of Change
Summary of Completed Tests