Open vinayan3 opened 1 month ago
@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 😃
@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
.
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.
@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 -- 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.
@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 thefetchExperimentRuns
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
).
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-L228If
ExperimentNames
is empty it shouldn't be included in the query on the DB.