Previously, LAST_ONLY was running the latest ready action. The gap was that it was picking up even the old ready instances after that.
Actually, previously LAST_ONLY was basically the same as LIFO. And from what I could tell, it hasn't worked properly for at least 3 years.
But the current implementation changes the meaning of LAST_ONLY to run only the latest nominal time
The meaning of LAST_ONLY was never clearly specified. From the documentation, it only had this: "discards all older materializations". That's pretty vague and could mean a few different things. After Bowen's attempt at this JIRA, and then my earlier attempts, it was getting too complicated and we kept find edge cases that we couldn't fix. t finally decided that LAST_ONLY could be interpreted as essentially the same as having a timeout equal to the frequency, but with a "good" ending status (see this comment and later).
Is there a usecase for the current implementation of LAST_ONLY. If there is
LAST_ONLY is good if you have a coordinator where you don't necessarily care about the specific instances that it runs, just that it runs. Specifically, we had a customer who had a coordinator with LAST_ONLY and was expecting this behavior. They brought down their Oozie server for a while for maintenance; when they brought it up, they were expecting Oozie to ignore the "missed" instantiations and just do the last one and continue normally after that, but it instead played "catch up" and started them all. That's why I wanted to fix this; otherwise, nobody has complained that LAST_ONLY hasn't worked in 3 years... I imagine most users don't even know that you can change it to LIFO or LAST_ONLY.
I will add another enum which executes latest ready action and discards the rest.
Feel free to add another execution strategy. Bowen Zhang has already created a new one called NONE in