Model/applications/modelling_e2e
Jun-te Kim b1ff711260 perf(modelling_e2e): batch SubTask bookkeeping to stop per-property writes
Even after batching the data writes, the handler still wrote to the DB per
property through the orchestrator's SubTask bookkeeping: create + start +
complete each self-committed, and _cascade re-listed every sibling and re-saved
the parent on every transition — ~5 writes per property plus an O(N^2) cascade.

- TaskOrchestrator.run_subtasks: create all children in one INSERT, run each
  (failures isolated per child), then persist all terminal states in one bulk
  save and cascade the parent once. Children go WAITING -> terminal; the
  transient IN_PROGRESS row is never written.
- SubTaskRepository.create_many / save_many (bulk INSERT / bulk fetch + update).
- _cascade short-circuits when the Task is already FAILED (terminal) — skips the
  sibling roll-up entirely.
- modelling_e2e handler fans out via run_subtasks instead of per-property
  create_child_subtask + run_subtask.

Per N-property batch the SubTask bookkeeping drops from ~5N writes + an O(N^2)
cascade to ~2 writes + 1 cascade.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-24 19:26:42 +00:00
..
local_handler remove smoke tests from gh workflows 2026-06-24 11:35:30 +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 perf(modelling_e2e): batch SubTask bookkeeping to stop per-property writes 2026-06-24 19:26:42 +00:00
modelling_e2e_trigger_body.py process multiple properties in one message 2026-06-22 15:46:18 +00:00
requirements.txt various fixes 2026-06-22 14:21:52 +00:00