I agree with Josh's assessment
- that such flag already exist, and we are using different flag value per different actions.
- that we would just work on pipeline reset action to clear selection. I don't know how feasible it is for the region to remove only successful run selections. Even though a run might finish fast, it's probably still in a background job and not synchronous. Removing all selection regardless of run status seems more realistic to me.
BUT, looking at the code, RetryStatusAction already clear all the dataregion selections, see DataRegionSelection.clearAll(getViewContext()). The key step to repro the client's scenario is "If you do this too quickly"... So if I understand this correctly, this is a race condition that the client is describing. Tab 1 selects A, tab 1 hits "Retry", tab 2 selects B, tab 2 hits "Retry" (both A and B are retried, B is selected from current form checkbox, A is from session), tab 1 finished retry and clear selection. Those type of scenarios with accessing a shared resource are common with a multi user setup. And the correct behavior is what we are currently doing: show error to tab 2 "hey, A cannot be retried...".
If we care enough to modify pipeline grid, perhaps we can force the retry action to only fetch from from checkbox, but don't look at session. I estimate that to be 1-3 hours.