Scheduler CRON gets failed when node status is already in unpublished or draft state

Added a patch for checking published state.

Appears to have test failures that will have to be addressed

Patch #5 failed to apply for me.

PHP 8.2

Fixes will need to be against 3.0.x

Patch #8 works for me on 3.0.x.
Only a slight change was needed in #2 patch.

Patch #9 for 3.0.x.
Only a slight change on #2 patch (return -> return 0).

Patch for 3.0.x.
Only a slight change on #2 patch (return -> return 0).

Patch for 3.0.x.
Only a slight change on #2 patch (return -> return 0).

Patch for 3.0.x.
Only a slight change on #2 patch (return -> return 0).

Patch for 3.0.x.
Only a slight change on #2 patch (return -> return 0).

Patch for 3.0.x.
Only a slight change on #2 patch (return -> return 0).

Fixes should be in MR.

Working on it.

Hello @smustgrave,
I applied the patch provided in #8 and it successfully applied, so i have provided MR as requested,
Please review.

Updated the patch to address a bug which results in potentially thousands of revisions being created if the content editor happens to transition to the target moderation state before the scheduler is able to handle it.

It keeps failing and creating new revisions because:
1. It's unable to transition back to itself.
2. The target moderation state is set to NULL.

Can we get a simple test case added

Yes we need test coverage for this changes. I made a commen in the MR and test coverage would hopefully show that error.

Is anyone on this thread starting to work on adding test coverage? If no one is, then I will, but do not want to waste/duplicate effort if you have already started. If I don't hear back in a couple of days, I'll start on it.

I assumed that this error was easily reproducable, but I just tried to follow the steps above. At step 3

3. Then manually transition to that "unpublished" state before the date.

how exactly is this achieved?

My workflow has "archived" as the unpublished state which cannot transition to itself, but that is just a name difference. If you edit the node and select the archived state manually I get the following validation error
and you cannot save.

If I use the content views I am also prevented from saving the manual change

I presume there is another way that the moderation state can be changed manually, so please can this be added in to the Steps to Reproduce in the summary.

Thanks for taking this up, I wasn't able to replicate the issue using the UI since the constraint validation stopped it from occuring.

I just came across the entity with the unpublish_state as it was (NULL), but not exactly sure how it got to that state. Just that it couldn't get itself out of the state.

Looking at the revision history, the state was as follows:

So it's possible the state was changed using a different mechanism that didn't check for validation constraints (not sure as there are no revision log messages for it).

Either way, in the event that an invalid transition is reached, the current error handling is such that it'll always clear the target state, and after the module returns -1, it'll be resaved with the now NULL target state and result in the loop.

I think the way to provide a test case for it is to change the moderation state directly rather than through the UI, so that the -1 cases can be properly tested for.

Thanks @codebymikey it is helpful to know that I was not missing something simple. Yes I agree even this scenario is hard to replicate in normal circumstances we still need to cater for it and prevent the loop. I can work on a test for this.