Daniel Roth f7328f54c5 Fetch a property's lodged EPC by UPRN, not property_id ... An epc_property row can carry a null property_id (FE/historic ingestion persists EPC rows never linked to a property row), so a property_id-keyed read silently misses them. UPRN is the durable key both the property row and the epc_property row share. Repoint the lodged reads (get_for_property + get_for_properties) onto UPRN; the predicted reads stay on property_id because a predicted EPC deep-copies a neighbour's UPRN, so its UPRN column is never the property's own. UPRN is not unique on epc_property, so the read tie-break is now load- bearing (it was dormant under property_id, where the write path guarantees one lodged row per property): the most recently ingested (highest-id) row wins. Write path stays keyed on (property_id, source). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>		2026-07-14 10:35:51 +00:00
..
__init__.py	process multiple properties in one message	2026-06-22 15:46:18 +00:00
test_handler.py	Fetch a property's lodged EPC by UPRN, not property_id	2026-07-14 10:35:51 +00:00
test_predict_epc_errors.py	Fail unmodellable properties with a specific, debuggable error 🟩	2026-06-24 14:13:28 +00:00