Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Displaying log output like that is just wrong and should be removed.
Comment | File | Size | Author |
---|---|---|---|
#7 | ultimate-cron-message-thread-2731421-7-interdiff.txt | 1.84 KB | Berdir |
#7 | ultimate-cron-message-thread-2731421-7.patch | 5.68 KB | Berdir |
#6 | ultimate-cron-message-thread-2731421-5.patch | 3.84 KB | Berdir |
#5 | ultimate-cron-message-thread-2731421-5.patch | 3.84 KB | Berdir |
Comments
Comment #2
mtiftI think you are referring to this: http://cgit.drupalcode.org/ultimate_cron/tree/plugins/ultimate_cron/laun.... Moving to that project's issue queue.
Comment #3
BerdirSorry, was on the wrong tab :)
Thanks for moving.
Comment #4
BerdirExtending this to also figure out why it always reports them as being started manually
Comment #5
BerdirOk, turns out this is because of the launch() indirection. So it creates a new scheduler instance and that doesn't have the current thread. There is a todo to statically cache those plugin instances but even then, it would still be per plugin.
There's a bigger problem there, but this resolves itself for now when we kill off that level of indirection and call $this->launch($job) instead of $job->launch() that would then do the same.
Comment #6
BerdirHello testbot?
Comment #7
BerdirI guess I broke testbot by creating this in the wrong project first.
Anyway, here's a test only and combined patch that I tested locally.
Comment #9
BerdirCommitted. Lets hope this passes on testbot as well ;)