Show job ids on job success#20145
Conversation
|
How does this work for map over jobs ? |
In the case of more than one job, this view remains unchanged. But I need to test map over jobs locally, and add something for those too. |
|
I think we should be consistent here and show the same screen independently of what type of job the user submitted. However I am worried about performance. The reason why this doesn't take down the server for a large map over step in the invocation view is that we get the job states via the invocation step. We'd either need to add an API route that lets us query for pre-specified job ids, or we wait for #17393 which stores the job request itself and use that as the anchor, I don't think we can pull the state for thousands of job ids (or even just a handful is gonna make up a significant fraction of traffic). So if we want to get something in for this release, why don't we add the link to the job to the job info component for now ? |
So, you mean what I showed in the screenshot above with those links? And if yes, then in the case of a singular job, we still show the job info component here like in the screencast? |
|
I think we should be consistent. So the same link for the single job would be my preference. |
Is a step towards galaxyproject#20014. Currently, showing multiple jobs in this view can be expensive (as mentioned here galaxyproject#20145 (comment)).
440d10f to
700cb95
Compare
|
Reduced this to: show_info_on_job_success_2.mp4(First I demo a single job, then mapped over 2 jobs) Updated the main PR screencast to this |
Without this change, it wouldn't show anything after `It produces this output`
|
Awesome, thank you @ahmedhamidawan! |

Fixes #20014
show_info_on_job_success_2.mp4
Initial Implementation where we show the job information
show_info_on_job_success.mp4
This ^ is on EU where we have a webhook as well as tool recommendations.
Otherwise, only the job information is shown.
How to test the changes?
(Select all options that apply)
License