History Consistency

[gdpodesta]

In processing 500+ legacy jobs, I've discovered the the 3 sources of job history all have varying results:

• API /monitor
• API /history
• Web interface

Clearing logs from the Monitor, leaves records in the API and Deleting rows in the Web Interface leaves them in the API.
Ideally, all History lookups would reflect what the Webinterface is showing since it has the greatest flexibility in deleting records.

Additionally, specifying how many history records to show, or which workflow(s) to include would be good. As it is, I'm getting 200 legacy completions that I've deleted from the webinterface, but they continue to show up in the API History, and there's no way to filter them, or get beyond them to the Production history that is I'm actually interested in.

[emcodem]

Hey @gdpodesta,

great request and totally understood.
Currently the webint pulls jobs from the native ffastrans api and sorts them into it's own database, so the webinterface is at the same level as "your API consuming program" - it is just an external program that uses the ffastrans API.
There are multiple reasons why "changes" in the webinterface internal job database does not reflect in the monitor, first of all reasons is that the webinterface is not a native part of ffastrans. As of now, the webint is designed not to be able to influence ffastrans installation anyhow, ever; no matter if it is just about deleting files or text in files or something different.

Anyway, the API get a major update (hopefully this year) and your request is totally noted

While i am not 100% certain how exactly the answer body of the new API getjobs call will look like, you could currently just go for the Webinterface internal API to get the job list:
http://localhost:3002/gethistoryjobsaja ... rchterm%22}

If you go that route, i'd recommend to install one version of the webinterface ONLY for the API stuff that you do (and a second one for the users). You don't need to update frequently the installation that for API use only. - note that the payload of the inernal historyjobs call of the webint may change frequently.

[gdpodesta]

That is SPECTACULAR! Is there a WebInt API call for the Running jobs that I could use as well?
I tried 3002/getactivejobsajax_treegrid.js , but it responds with 404 and "Cannot GET /getactivejobsajax_treegrid.js" even through there is a job running and showing on the WebInt.

[emcodem]

Ay GD, sorry for the very late reply!
So, you are right, the call to getactivejobsajax_treegrid.js is broke, but all it actually would do is to force a refresh of the activejobs so the client does not have to wait 3 seconds until the data is displayed.
What happens in the background is that active jobs are not actually stored in the internal database of the webinterface but instead just pushed to all opened webinterface instances. Thats because the active jobs are not considered as static data but as dynamic data, so no need to store the stuff.

Originally i wanted to combine all jobs into one big list which in my head could make the life of API implementers easier but the problem is that active jobs constantly update their state so they need to be handled differently than static history jobs.