[release-testing] Applying a cutoff time on admin jobs page does not show any jobs unless the cutoff time is very large

[simonbray]

Testing #13893.

If the job cutoff filter on the admin jobs page is not selected, all running jobs are listed (as expected).

If the job cutoff filter is selected, no jobs are listed for the default time of 5 minutes (even after checking the page immediately after starting a few new jobs.) Jobs are only shown If the cutoff time is set to a really high value (ca. 900 minutes or more).

[dannon]

@simonbray Can you add a screenshot of what you're seeing maybe? When I test a local job here, I see the following, which looks correct. I ran a job, waited for it to finish, then kicked off another job (random lines with an extra sleep I added in to make it run for a while), and it's showing up for me.

[dannon]

I'm going to close this one out since it seems to be working well in my testing. If we can reproduce the failure feel free to reopen!

[simonbray]

Hi @dannon, I've been offline for a couple of weeks but tested again today (the same way as you described). Here are some screenshots.

Cutoff time of 100:

Cutoff time of 1000:

[dannon]

Interesting! Can you pop open the web console and look at the requests being generated, something like:

GET | http://localhost:8081/api/jobs?view=admin_job_list&date_range_min=2022-07-05T12:16:37.639Z

And see if anything looks fishy with the date_range_min specified there? Mine does correctly translate my local time to Zulu/UTC, which is what the Galaxy server will be using internally. I'm wondering if something is weird with time handling?

[simonbray]

For 100 minutes:

http://localhost:8080/api/jobs?view=admin_job_list&date_range_min=2022-07-05T13:05:51.206Z

For 1000 minutes:

http://localhost:8080/api/jobs?view=admin_job_list&date_range_min=2022-07-04T22:06:23.994Z

After a bit of tinkering I found that an API request with 2022-07-04T23:59:59 gives all the jobs I ran today whereas 2022-07-05T00:00:00 gives nothing - can it be that everything after T is being thrown away?

[mvdbeek]

Yeah, I think that needs to be urlencoded ?

[simonbray]

I tried URL-encoding the string but it doesn't make a difference.

[davelopez]

Fixed in #14281

[mvdbeek]

Seems to have re?-appeared now, I wonder if we also need to urlencode the time / use the params object in axios.

[mvdbeek]

It's not the urlencoding, the problem is the Zulu postfix, which means we get UTC times, while all our sqlalchemy / database times do not carry the tzinfo ...

In [1]: from pydantic import BaseModel

In [2]: from datetime import datetime

In [3]: class Time(BaseModel):
   ...:     time: datetime
   ...:

In [4]: Time(time="2022-08-15T13:37:32.05700Z")
Out[4]: Time(time=datetime.datetime(2022, 8, 15, 13, 37, 32, 57000, tzinfo=datetime.timezone.utc))

In [5]: Time(time="2022-08-15T13:37:32.05700")
Out[5]: Time(time=datetime.datetime(2022, 8, 15, 13, 37, 32, 57000))