Runs cache is not automated

[slominskir]

The Run table needs to be populated and maintained in an automated fashion.

The PAC Schedule database can be examined to determine the bounds of runs, but it is complex so runs are now determined in advance and cached in the btm_owner.run table. Ideally this cache of runs is kept up-to-date in an automated way when schedules are modified. Also, the initial population of runs from the existing database would be useful. Currently, just the most recent two runs are in the run table, and they were manually inserted, and new runs can be missed if not manually added.

Historically the run determination was automated and calculated on the fly each time the /rest/runs endpoint was requested. This was costly to calculate, plus assumed all months had data (explicit OFF) for SAD times. If SAD times were not explicit the automated routine found zero results.

[slominskir]

Worth noting that only the most recent two runs (current and previous) are actually used at the moment. Used by the date range selector in smoothness reports

[slominskir]

Also worth noting we could just have a setup page allowing add/edit runs. This has the advantage of allowing ACTUAL run to not match SCHEDULED. This is what is happening at the moment where PAC version 2 says we start restore on Aug 28 but we actually started restore on Aug 26.

[slominskir]

Also worth noting it appears HTTP cache headers caches JSON response for 24 hours.

https://ace.jlab.org/btm/rest/runs