mqtt_logger: incomplete MQTT payloads partially overwrite the cached field set #2
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Records are emitted from a cached field set that each topic refreshes when it publishes. When a JSON topic delivers a payload that is missing one of its expected fields, the fields processed before the missing one have already been written into the cache. The next emitted record can therefore mix values from a half-delivered payload with values cached from earlier publishes, producing internally inconsistent records with no outward sign. Analysis code has no way to detect that this happened.
Observed in the field: schema-boundary records (e.g. sun elevation present but gate states absent for days after a cutover) show the cache refresh process is not atomic in practice.
Findings
on_messagewrites each field into thelatestcache as it iterates; a missing field raises KeyError partway through, leaving the fields before it already overwritten.freshis not marked, so no record is emitted from the bad payload — but the poisoned cache leaks into the next good emit.zappi/readingspayload then an incomplete one (first fields present with different values, later fields absent) leaveszappi_charge_modemutated (Fastinstead ofEco). Test initially passed with same-value sentinels — partial merge was invisible — so the test uses differing values.Plan of attack
latestonly if every field is present (single atomic update).test_mqtt_logger.pyas a standalone PEP 723 unittest script (style oftest_analyze.py); cases: complete payload updates all fields, incomplete payload mutates nothing, cache recovers on next complete payload.:bug: reject incomplete MQTT payloads without touching the field cacheon branchfix/issue-2-mqtt-logger-quality.