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
..
local_handler	Update trigger script and local invoker to use refetch_solar, refetch_epc, repredict_epc 🟩	2026-06-26 10:17:20 +00:00
Dockerfile	move handler stuff to applications directory	2026-06-22 13:35:23 +00:00
errors.py	Fail unmodellable properties with a specific, debuggable error 🟥	2026-06-24 14:10:55 +00:00
handler.py	Fetch a property's lodged EPC by UPRN, not property_id	2026-07-14 10:35:51 +00:00
modelling_e2e_trigger_body.py	An attach-mode batch models under the supplied sub_task without children 🟩	2026-07-07 11:53:26 +00:00
requirements.txt	various fixes	2026-06-22 14:21:52 +00:00