Circular reference detected for service "cache.backend.database".

Same issue.

The same issue mentioned in https://www.drupal.org/project/lightning_scheduler/issues/3297525#commen... 📌 Automated Drupal 10 compatibility fixes Needs work

Same issue here.

Same issue here

The provided patch won't apply - it just times out after a while. I will try doing a re-roll of this patch, test it and then attach to this comment shortly.

We can ignore the patch added in https://www.drupal.org/project/lightning_workflow/issues/3389692 🐛 Creation of dynamic property Drupal\lightning_scheduler\Time::$_serviceId is deprecated RTBC because it will be addressed by the temporary fix in patch #77 for now.

#11 🐛 Circular reference detected for service "cache.backend.database". Active installed cleanly, brought site back up. Running additional tests, but so far so good! @sundhar →

+++ b/modules/lightning_scheduler/src/Time.php
@@ -12,30 +13,59 @@ use Symfony\Component\HttpFoundation\RequestStack;
+    return $this->get('lightning_scheduler.request_time', parent::getRequestTime());

Should this not be calling get() on the $this->keyValueStore (patch from #11 🐛 Circular reference detected for service "cache.backend.database". Active )?

Hi @greeenskin,

State service dependency creates a circular reference, so I removed that dependency and implemented the functions in the 'lightning_scheduler.datetime.time' service. I used $this->get('lightning_scheduler.request_time', parent::getRequestTime()); in that callback.

Thankyou

Hey everyone, what's the difference between the lightning scheduler sub-module of this module and the standalone lightning scheduler → module? The standalone module seems to have addressed the issue.

Why not simply make that module a dependency of this one via composer? Or remove it completely, leaving it to the person building the Drupal site to decide what scheduling module they want to use and add it explicitly to their project?

Seems silly to maintain this independently as part of the lightning workflow codebase when the other is having the same kinds of issues being addressed separately ( https://www.drupal.org/project/lightning_scheduler/issues/3297525 📌 Automated Drupal 10 compatibility fixes Needs work ).

By the way, it looks like the latest release of the standalone module has this whole problem and other related issues resolved.

I found that if I Remove this patch from Composer.json

"drupal/calendar": {
"#3396700: Creation of dynamic properties is deprecated": " https://www.drupal.org/files/issues/2023-10-26/calendar-dynamic-properti → ..."
}

The error goes away.

same issue

I just replaced the files inside the submodule with the files of the standalone → module and problem solved.
Thank you @teknocat for letting us know the problem solved for the standalone module!

I agree with @teknocat can't this submodule be removed?

Updated the patch to work with
"drupal/lightning_workflow": "4.0.0",
"drupal/core-recommended": "10.3.6",

Any news on this guys?

Removing lightning_scheduler.datetime.time dservice from services.yml appears to solve the issue, but i'm afraid of having colateral effects on deleting it, is it safe to deleted? There are any definitive fix comming?

I could not apply patch suggested in #24 by @farnoosh, however the suggestion by @teknocat in #8 helped: i replaced the files in lightning_scheduler completely by the files from the standalone version: https://www.drupal.org/project/lightning_scheduler → 8.x-1.6

That did the trick for me, no problems found so far.
Attaching a patch that replaces the lightning_scheduler with its standalone version

Previous patch did not apply, updating the correct patch

As a workaround, I created a new branch of Lightning Workflow that removes the Lightning Scheduler Module and creates a dependency on that contrib project.

See the 5.x branch.