Closed asizemore closed 1 year ago
This code looks good. However, I'm wondering if we should automatically restart a job, if it is expired, rather than forcing the user to intervene.
Interesting idea. Let me see if i understand. We (the client) don't know a job is expired until a user changes to those parameters. This means we couldn't rerun it until after a user sees that the compute results aren't ready immediately even though they should be. For fast computations this wouldn't be a problem because they'd get those results again right away, but for something like beta div they'd see that the job was running when they came to those parameters (after maybe a brief messaging saying that the job is expired so we're gonna rerun it).
I think that is pretty clear to a user, but if the user does not really care about restarting that job then we are restarting then storing results for an unrequested job. How cautious are we trying to be with preventing such jobs?
I'm going to back-pedal on automatically restarting expired jobs. I don't think the UX will be good, due to the overview page. I definitely don't think we want to restart jobs automatically on that page, so we would end up displaying the expired status there. It would probably be confusing to then open one of those vizs and see the job in a running state. Sorry for the rabbit trail!
Resolves #1637
Could use some ux feedback on the exact verbiage before merging.
As of right now, the button is active for expired jobs, but when i click the button i see "Requesting" for a moment and then the same expired status. My guess is that when we send that job request to the cs, it's not rerunning. But maybe there's something else going on!
Also i've only found the one expired job so far, so if i successfully get it to restart, we will have 0 known expired jobs that we can use to test :) So i took some screenshots of what things look like: