[krixkrix]

Summary

GET /api/executions (the Build History list, full and ?since= deltas) ran about six SQL queries per execution. It now runs one query per request, whatever the list length.

 CAPIHandler_Executions::handleListExecutionsRequest
   ListJobExecutions / ListJobExecutionsChangedSince        # 1 query
   for each execution
-    GetStatus, GetStatusString, GetDescription             # 1 query each
-    GetEndTimeStampInMicroseconds, ComputeElapsedTime...   # 1 query each
-    RetrieveJob -> HasThumbnailStream                      # 1+ query
+    writeExecutionListEntryToJSON                          # no query
+      GetLoadedStatus, GetLoadedDescription, ...           # values loaded by the list query

• LibMCData: the execution SELECT now also loads status, description, end time stamp and the job's thumbnail. New getters return them: GetLoadedStatus, GetLoadedStatusString, GetLoadedDescription, GetLoadedEndTimeStampInMicroseconds, ComputeLoadedElapsedTimeInMicroseconds, JobHasThumbnailStream and GetJobThumbnailStreamUUID. The existing getters still read fresh from the database, so plugins see no change.
• The SELECT was copied into five queries whose column order had to match by hand. It is now one shared CBuildJobExecution::selectQueryWithoutConditions().
• A damaged job row (missing row, unparseable status, malformed thumbnail UUID) used to fail the whole list and every delta. It now affects only its own entry.
• DevTools/executionlist_perf/ seeds N executions into a scratch MinimalSystem server and measures the list, so the numbers below can be reproduced.

Evidence

executionlist_perf.py run -n <N>, same seeded database before and after, -O0 dev build, median of 5:

	before	after
full list, 2000 executions	1212 ms	63 ms
6 concurrent full lists, 2000 executions	8.3 s	0.18 s
100-row ?since= delta, 2000 executions	65 ms	5 ms
full list, 100 executions	23 ms	5 ms
list with one orphaned execution (--damaged 1)	request fails	200 OK

• Before: the cost grows with the length of the list, so a few clients opening Build History on a device with a long history keep amc_server busy for seconds.
  After: the /api/executions response bodies (full, since=0, since=head-10, since=head) are byte-identical to before.
• New unit tests in LibMCData_BuildJobs all pass, as does the rest of amc_unittest (487 of 487):
  • ListExecsLoadedValues: every execution query loads the right values.
  • ListExecsLoadedIsSnapshot: the loaded getters keep the listed values, while the fresh getters re-read the database.
  • ListExecsMalformedJobRow and ListExecsOrphanedExecution: a damaged row degrades only its own entry.
  • ListExecsJSONEntry: the entry JSON written from the loaded values.

Merge Danger

Door: two-way

The ACT changes only add methods. There is no schema migration, and the JSON format is unchanged.

Blast Radius: small

It touches every place that builds execution objects: ListJobExecutions, ListJobExecutionsChangedSince, RetrieveJobExecution and RetrieveBuildJobExecutions[ByStatus]. A bug in the shared SELECT would therefore show up in all of them. The unit tests cover each of those paths. Plugins that hold long-lived execution objects keep the fresh-reading getters.