jamesdumay that's what we had originally and you guys complained that there wasn't immediate feedback to the user acknowledging that they had pressed the run button. So you want to remove the "Queued" toast again and just have the "Started" one?

I think the requirements may have not have been clear (my fault).

When the user hits the run button the "Started OPEN" toast should show immediately (on successfully queuing the run). If we click the open link it should show the result details modal - doesn't matter what state it's in (from a users PoV queued is just another status - shouldn't be treated any differently though the backend does).

Fair enough. I'm fairly sure the run modal will only work with a run instance, which is not available at this point, so it will require refactoring so that it actually works off the queueId of the run Vs the runId ... I have a feeling it will get messy.

I'd imagine so. I think hadashi is working in that area at the moment. michaelneale can you chime in here and clarify if someone is working on making the run modal work off of a queued item?

Reopening after talking to jamesdumay ... he wants to change how this works so that the run details modal also works with only having a queue item (i.e. without a run) and so we get rid of the "Started" toast.

So .... we need to move the "OPEN" link to the "Queued" toast and zap the "Started" toast completely. That part is trivial.

I suspect that the hard part is the refactoring of how the run modal works because it needs to be wired to the redux store in such a way as to accommodate the fact that it started life without a run (or with a "fake" run that only has a queueId and does not have a runId) and then morphs once the run actually becomes available. Sounds tricky, but maybe it's not so bad.

jamesdumay from conversation earlier in the week with imeredith, yes in theory he was taking into account a modal (pipeline results) that jumps from looking at a thing in a queue to an actual run. I believe the word "hack" was mentioned a few times, so yes

michaelneale This artificial backend difference between a queued item and a run just seems so knuckle-headed to me (and from a users perspective). I've no idea why Jenkins ever created the distinction Vs just treating them all as Runs with different states and "QUEUED" being just one of them.

I haven't thought too hard about this yet but maybe we can come up with a way of merging these worlds inside the client UI code. We could create a Run class that represents queued items as well as runs, with the redux store updating/morphing the instances it has based on SSE events. That way, I think the UI react components can just treat them the same from a referential point of view.

tfennelly yes it is a pain, and over time this artificial dichotomy will go away, but for now, it is what it is. The last I spoke with imeredith he was looking at creating an /activity stream end point which combines this in the blue ocean middle tier (but things may have changed, or I may be misremembering) to try and unify it. There has to be some temporary (ish) uglyness somewhere so it needs to be in testable code.

Please read the description of this ticket and ensure that all run buttons have this behaviour.

See https://issues.jenkins-ci.org/browse/JENKINS-36199