You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When launching an experiment through the UI, it correctly spawns the expected jobs and they are successful. However, the UI receives a 422 error under the hood when trying to retrieve the jobs.
Not necessarily a frontend issue, as many things shifted on the backend side since the previous PR.
Reproduction
make start-lumigator-build
Upload a dataset with gt (e.g. from sample_data, take dialogsum_exc.csv)
Use in experiments: any title, any description, limit to 2 samples (that's enough)
Select any model from self-hosted and or, if you set an API key, from the corresponding API
Open the console
On the UI click on "Launch experiment"
See the 422 error in the screenshot
Relevant log output
{
"detail": [
{
"type": "uuid_parsing",
"loc": [
"path",
"job_id"
],
"msg": "Input should be a valid UUID, invalid length: expected length 32 for simple format, found 1",
"input": "1",
"ctx": {
"error": "invalid length: expected length 32 for simple format, found 1"
}
}
]
}
Expected behavior
It should be possible to GET /jobs . Not sure this is necessarily a frontend issue, as many things shifted on the backend side in #740 .
This issue seems to be a leftover from the old implementation where it was trying to poll the jobs/:jobId endpoint to update the job and therefore the experiment level status as an aggregate thats shown in the UI.
So in this case it was passing an experimentId such as 1 or 2 which is incremental to the jobs/:jobId endpoint which expected the job Id to be a uuid, hence correctly throwing a 4XX validation error.
This should be fixed by #887 where the frontend will poll for the incomplete workflows separately and set an experiment level aggregate to filter incomplete experiments instead of trying to poll for specific jobs like with the old implementation
Description
When launching an experiment through the UI, it correctly spawns the expected jobs and they are successful. However, the UI receives a 422 error under the hood when trying to retrieve the jobs.
Not necessarily a frontend issue, as many things shifted on the backend side since the previous PR.
Reproduction
Relevant log output
Expected behavior
It should be possible to GET /jobs . Not sure this is necessarily a frontend issue, as many things shifted on the backend side in #740 .
System Info
Have you searched for similar issues before submitting this one?
The text was updated successfully, but these errors were encountered: