(bugfix) Make Experiments Overview Page Show Dates & Runs

[vinayan3]

Date fix

The server is sending data in camel case which causes the experiment overview page to show invalid date instead of the actual date. The expected data type is here: https://github.com/G-Research/fasttrackml-ui-aim/blob/release/v3.17.5/src/src/modules/core/api/experimentsApi/types.ts#L84-L90

Before the change

After the change

Runs fix

When you click the runs tab it make an API call to the AIM end points for GET /runs/search/run. The UI's code sets the experiment as a query see:
https://github.com/G-Research/fasttrackml-ui-aim/blob/release/v3.17.5/src/src/pages/Experiment/components/ExperimentRunsTab/ExperimentRunsTable/useExperimentRunsTable.tsx#L224-L228

If ExperimentNamesis empty it shouldn't be included in the query on the DB.

[jescalada]

I tested all the issues we were having in #1334 and it looks good to me! The code looks fine as well.

Pinging @suprjinx for feedback on the query just in case.

[jescalada]

@vinayan3 It seems however that some of the Go tests related to Run Searching are failing ATM. Let's make sure that those are passing first 😃

[vinayan3]

@jescalada so I'll need to change the test NoExperimentNamesNoResults . The behavior is now different where if you don't provide an experiment name then it allows all. Instead it'll be NoExpeirmentNamesResultsFromQuery.

[suprjinx]

Great idea -- but I think we need to limit runs returned when no experiment names are provided. Additionally, I think SearchRuns should always require the experiment selection -- maybe a new repository function for use in the overview which returns most recent runs?

[vinayan3]

Great idea -- but I think we need to limit runs returned when no experiment names are provided. Additionally, I think SearchRuns should always require the experiment selection -- maybe a new repository function for use in the overview which returns most recent runs?

Could a solution here to be add a limit field to the API request and make experiment names or limit required?

Otherwise, I'm fine with adding a new request for the overview call.

[suprjinx]

@vinayan3 -- I think maybe we should keep your changes for creation_time, end_time serialization in this PR, and then open a new PR in the UI repo. The runs tab in the experiment overview is issuing a request like this:
http://localhost:5000/aim/api/runs/search/run?limit=50&exclude_params=true&q=run.experiment%20==%20%27my-experiment%27

But we need it to issue one like this:
http://localhost:5000/aim/api/runs/search/run?q=&experiment_names=my-experiment&limit=45

So we would just alter the fetchExperimentRuns function you highlighted to structure the params differently, and it should work.

[vinayan3]

@vinayan3 -- I think maybe we should keep your changes for creation_time, end_time serialization in this PR, and then open a new PR in the UI repo. The runs tab in the experiment overview is issuing a request like this: http://localhost:5000/aim/api/runs/search/run?limit=50&exclude_params=true&q=run.experiment%20==%20%27my-experiment%27

But we need it to issue one like this: http://localhost:5000/aim/api/runs/search/run?q=&experiment_names=my-experiment&limit=45

So we would just alter the fetchExperimentRuns function you highlighted to structure the params differently, and it should work.

I'll have to work through hitting a new endpoint in the UI later this week.

[suprjinx]

@vinayan3 -- I think maybe we should keep your changes for creation_time, end_time serialization in this PR, and then open a new PR in the UI repo. The runs tab in the experiment overview is issuing a request like this: http://localhost:5000/aim/api/runs/search/run?limit=50&exclude_params=true&q=run.experiment%20==%20%27my-experiment%27
But we need it to issue one like this: http://localhost:5000/aim/api/runs/search/run?q=&experiment_names=my-experiment&limit=45
So we would just alter the fetchExperimentRuns function you highlighted to structure the params differently, and it should work.

I'll have to work through hitting a new endpoint in the UI later this week.

Cool thank you! I think it's not even a new endpoint, just changing the param structure in the ajax request (from q to experiment_names).