Last_run in list_resources view is effectively the first run

[fsteggink]

When trying to come up with a fix for issue #326, I noticed some code in which all kinds of info about resources is gathered in a loop. In this code the first and last runs of all (filtered) resources is determined as well. However, I've noticed that the comparison operator is "less than" in both cased.

See the following code in views.py, function list_resources:

    for resource in response['resources']:
        if resource.run_count > 0:
            # View should work even without Runs
            if first_run is None or resource.first_run < first_run:
                first_run = resource.first_run
            if last_run is None or resource.last_run < last_run:
                last_run = resource.last_run
            response['first_run'] = first_run

I've also noticed that, although first_run and last_run are stored in the response object, they don't appear to be used anywhere. This might also be the case for other variables collected in list_resources and other functions. Cleaning this up should also improve the performance, as reported in issue #326.

[justb4]

first_run and last_run are first and last Runs over all Resources. These are used in the overall_status.html template, e.g. used/included by resources.html. It appears in top of web-UIs that list Resources, as e.g. Monitoring Period: 2021-08-23T15:16:07Z - 2021-08-31T10:04:14Z, basically the time-window for retention days.

The comparison operator < translates to comparison of the identifier Column of Run, but the comparison for last_run may be wrong: it will render the youngest last_run of all Resources. Think must be >. In terms of days that is usually not directly visible in the Monitoring Period.

[fsteggink]

The thing that is the most striking is that the comparison operator is < for both the first_run and last_run comparisons. One must be definitely wrong, unless first_run and last_run have different data types, which would be 😱