Sheduler upgrade 2.2.0 and content planer 8.x-1.2

Hi dpalicepeio@drupbuilder.org,
There was not much change in 2.2.0 → except to make it compatible with PHP8.4. There is nothing to force you to upgrade a module. It depends on your own procedures and how your site is set up. I can't help much more than that.

Maybe talk to the maintainers of the project that has the problem, and see if it can be fixed or if they can specify the maximum version of Scheduler that it is compatible with.

I am closing this as a duplicate, because you also asked the same thing in Content Planner 🐛 The content planner 8.x-1.2 not compatible with Scheduler 2.2.0 Active and that issue has more detail.

The event aliases we moved to .module in 🐛 TypeError: Drupal\content_calendar\EventSubscriber\SchedulerPublishSubScriber::onNodePublish(): Argument #1 ($event) must be of type Drupal\scheduler\SchedulerEvent, Drupal\scheduler\Event\SchedulerEvent given in Drupal\content_calendar\EventSubscriber\Sc Active But there are scenarios where a 3rd-party module has implemeted an eventSubscriber and the .module file is not loaded early in the process. Running a Database update is one case.

So Scheduler might be able to make things easier by re-instating the /src class files which contain the alias. We will need to investigate if there are problems in having them defined in both places. Or we may be able to use class_exists in the .module to prevent an error.

Attached a static scheduler--2025-01-17--3498553--mr-223.patch file for MR223 by Jonathan up to this point. ( Thanks, Jonathan!)
To be used with Composer Patches

Hi rajab natshah
Let me know how you get on. Does this solve your problem?
I can commit this and quickly release 2.2.1 if that will help you, providing that this is the correct fix and no side-effects.

• With that patch we'll just be re-introducing the issue we fixed in 🐛 TypeError: Drupal\content_calendar\EventSubscriber\SchedulerPublishSubScriber::onNodePublish(): Argument #1 ($event) must be of type Drupal\scheduler\SchedulerEvent, Drupal\scheduler\Event\SchedulerEvent given in Drupal\content_calendar\EventSubscriber\Sc Active .
• I think 🐛 class_alias calls not available when rebuilding container in ModuleInstaller Active might be related to the issue we're having here.
• I still can't reproduce the issue, but I'll start a MR to do it the way core did in #3214234: Add core/class_aliases.php →

{
  "type": "vcs",
  "url": "https://git.drupalcode.org/issue/entity_bundle_scaffold-3367659.git"
}

Make sure to add it before the https://packages.drupal.org/8 repository. Afterwards, run composer require drupal/scheduler:"dev-3498553-autoload-file as 2.1.0".

Never mind, autoloading class_aliases.php doesn't work either because when that file is autoloaded, the classes that are being aliased aren't autoloaded yet.

If I understand it correctly:

• The scheduler.module file is not always loaded, e.g. before a drush updb, so it's not enough to put the aliases there.
• The SchedulerEvent and SchedulerEvents aren't always autoloaded either. I have a suspicion that it has to do with the way the Composer autoloader is built. For example, as described here, when you dump the autoloader using --classmap-authoritative files with only a class_alias statement are not autoloaded.

The best option might be to - as you said - add these class_alias statements to both places and prefix them with @ to suppress errors. A bit dirty, but I don't know if there's a better way.

dieterholvoet → closed merge request !224

Thanks @dieterholvoet for working on this, and for the extra ideas. There is also more explanation on the issue linked from the one you added 📌 Resolve edge case where kernel event subscribers crash because class aliases aren't defined yet Fixed

I also have not been able to recreate the error, and I need to be able to do that to check that any change we make solves the problem. I have tried

• Fresh install of core 10.4 with Scheduler 2.0.1 and SCMI 3.0.3 and Content Planner 8.x-1.2
• Enable article for scheduling and add it to the default moderation workflow
• Update Scheduler to 2.2.0 and run drush updb

There must be more to it than this.

I've added @ to the class_alias() statements just for safety, but it is all a bit guess-work without being able to replicate the problem.

@rajab natshah in 🐛 The content planner 8.x-1.2 not compatible with Scheduler 2.2.0 Active you mentioned that this happens in a CI pipeline. Do you have a composer dump-autoload somewhere in that pipeline and if so, what options are being passed? Or is this also happening in environments where you didn't explicitly dump the autoloader?

Dieter, with you. Thanks for following.

Sometimes after drush site-install, the modules might not be fully enabled yet, or something like scheduler.module isn’t loaded properly. A quick drush cr right after can save trouble later!

Not using dump-autoload in the CI
Using the following in the composer

    "drupal/content_planner": "~1",
    "drupal/scheduler": "~2",

Having this simplified job

drush site-install  --locale="en" install_configure_form.enable_update_status_emails=NULL -vvv
drush pm:enable scheduler --yes
drush pm:enable content_planner --yes
drush cache:rebuild

Using MR223 to minimize errors

I have just been (accidentally) able to reproduce this issue when updating a project with scheduler and scheduler_content_moderation_integration. I can confirm that the current state of the MR fixes the issue. Not the cleanest fix, but good enough for now I'd say, because I have no idea how else to fix this.

I have just been (accidentally) able to reproduce this issue

That's good to hear. What info do you have about the update? here are some questions:

1. what core version?
2. what was the starting version of Scheduer?
3. what was the starting version of SCMI?
4. did you also have Content Planner module?
5. how many other updates were there? was it due to batching up some updates in groups?
6. were you doing it via website UI or drush or another way?

I am tempted to merge this MR but I still do not know if there could be any side-effects to having the aliases defined twice.