EasyIQ (0001): surface API errors and schema mismatches at WARNING level - #355
Open
spraot wants to merge 1 commit into
Open
EasyIQ (0001): surface API errors and schema mismatches at WARNING level#355spraot wants to merge 1 commit into
spraot wants to merge 1 commit into
Conversation
The legacy EasyIQ block wraps `Events` iteration in a bare
`try ... except KeyError: _LOGGER.debug("None")`. Any non-`Events`
response — including EasyIQ's `{"ErrorCode": "1", "ErrorDescription": "..."}`
error envelope, which it now returns aggressively for schools that
have migrated to SkolePortal but still have widget 0001 listed —
falls into the except and is logged at DEBUG level as the literal
string `"None"`. Downstream, the sensor attribute renders as just
`<h2> Uge NN</h2>` for every child with no log line at default
verbosity to indicate why.
Two changes:
1. After dumping the response at DEBUG, detect the EasyIQ error
envelope shape and log it as a WARNING naming widget id, child,
institution, week, ErrorCode and ErrorDescription.
2. Replace `except KeyError: _LOGGER.debug("None")` with a WARNING
that names the missing key and the response keys it did see —
so the next EasyIQ schema change isn't silent either.
Same UX for genuine empty weeks (the date-format check still
debug-logs to "None"-like lines). No change to the rest of the 0001
flow, no new dependencies, additive only.
This was referenced Aug 13, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The legacy EasyIQ block (widget
0001) wraps theEventsiteration in a bare:Any non-
Eventsresponse — including the EasyIQ error envelope{"ErrorCode": "1", "ErrorDescription": "..."}, which the API now returns aggressively for schools that have migrated to SkolePortal but still have widget0001listed — falls into the except and is logged at DEBUG level as the literal string"None". Downstream, the sensor attribute renders as just<h2> Uge NN</h2>for every child with no log line at default verbosity indicating why.This PR makes two small additions, no behaviour change for happy paths:
WARNINGnaming widget id, child, institution header, week,ErrorCodeandErrorDescription.except KeyError: _LOGGER.debug("None")with aWARNINGthat names the missing key and the response keys it did see — so the next EasyIQ schema change isn't silent either.Genuine empty weeks for a child still produce no warnings (the date-format check still DEBUG-logs to a
"None"-style line, just with more context).Why
Filed as a follow-up to the drive-by suggestion on #352. The silent-failure mode cost a couple of hours of diagnostic time before enabling debug logging revealed the actual
ErrorCode/ErrorDescriptionpayload. Surfacing it at default verbosity should save the next person the same archaeology.Test plan
python3 -c 'import ast; ast.parse(...)').0001.