Stuck in await after running two activities in parallel.

[chipotlegroove]

Hey all!

I'm trying out this package and got stuck trying to continue a workflow after using parallel activities and then using WorkflowStub::await to wait for approval for the two activities that ran previously.

Here is my workflow:

class MyWorkflow extends Workflow
{

    protected $approval1 = false;
    protected $approval2 = false;
    protected $approval3 = false;
    protected $approval4 = false;

    #[SignalMethod]
    public function setApproval1($approval1)
    {
        $this->approval1 = $approval1;
    }

    #[SignalMethod]
    public function setApproval2($approval2)
    {
        $this->approval2 = $approval2;
    }

    #[SignalMethod]
    public function setApproval3($approval3)
    {
        $this->approval3 = $approval3;
    }


    #[SignalMethod]
    public function setApproval4($approval4)
    {
        $this->approval4 = $approval4;
    }

    public function execute()
    {
        yield ActivityStub::make(CreateApprovalRequest1::class);

        yield WorkflowStub::await(fn() => $this->approval1);

        yield ActivityStub::all([
            ActivityStub::make(CreateApprovalRequest2::class),
            ActivityStub::make(CreateApprovalRequest3::class),
        ]);

        yield WorkflowStub::await(fn() => $this->approval2 && $this->approval3);

        yield ActivityStub::make(CreateApprovalRequest4::class);

        yield WorkflowStub::await(fn() => $this->approval4);

        Log::info("done");

        return "success";
    }

}

Each of my activities is just a logger that writes: "creating approval request for {RequestNumber}". Like this:

class CreateApprovalRequest1 extends Activity
{
    public function execute()
    {
        Log::info("creating approval request for 1");
    }
}

I run the signal methods using buttons on a Livewire component.

The first signaling works flawlessly and both 2 and 3 work when ran sequentially. Only when they are ran in parallel will CreateApprovalRequest4 not execute.

Any ideas as to what I'm doing wrong?
Thanks!

[chipotlegroove]

After staring at the screen for hours and finally deciding to write a post, a couple of minutes later I found a solution.

I ran CreateApprovalRequest2 and 3 sequentially (as all those do, is write to log and in the future save some models in the database I realized there is no need for them to run in parallel) and it worked.

Still I'm curious if what I was trying to do is possible.

[rmcdaniel]

Yep, what you were trying to do is absolutely possible with Laravel Workflow: you can run activities 2 & 3 in parallel and then await() a signal condition before running activity 4.

Your workflow is conceptually fine:

yield ActivityStub::all([
    ActivityStub::make(CreateApprovalRequest2::class),
    ActivityStub::make(CreateApprovalRequest3::class),
]);

yield WorkflowStub::await(fn () => $this->approval2 && $this->approval3);

yield ActivityStub::make(CreateApprovalRequest4::class);

There’s nothing in the engine that forbids that pattern. In fact, this is exactly the kind of “parallel + then wait on external signals” scenario the library is designed for.

Here are the most likely culprits and how I’d sanity-check them.

---

1. Make sure the workflow actually resumes after both parallel activities finish

ActivityStub::all() queues both activities and then the workflow job exits. When both activities finish, the workflow is dispatched again, its history is replayed, and execution continues past:

yield ActivityStub::all([...]);

If no workflow worker is running (or it’s on a different connection/queue), you’ll see:

• Activities 2 and 3 log fine
• But the workflow never comes back to process the next await() → activity 4 never runs

Check:

• You have a worker processing the workflow’s queue/connection:

  php artisan queue:work

• If you’ve customized $connection / $queue on your workflow or activities, the worker is using that same connection/queue.

Why you only see it with parallel: with sequential activities, the workflow is replayed between each activity anyway, so if your worker state is slightly off, it can look like it’s working while actually failing later in the run.

---

2. Confirm the signals are hitting the right workflow instance

Since you’re using Livewire buttons to call the signal methods, under the hood you’re doing something like:

$workflow = WorkflowStub::load($workflowId);
$workflow->setApproval2(true);
$workflow->setApproval3(true);

Things to double-check:

• The workflowId in Livewire really is the same one that started this MyWorkflow instance (especially if you’re starting multiple workflows during testing).

• The signal methods are annotated correctly:

  #[SignalMethod]
  public function setApproval2($approval2)
  {
      $this->approval2 = $approval2;
  }

If signals go to the wrong workflow, $this->approval2 / $this->approval3 in the workflow that’s blocked on await() never change, so:

fn () => $this->approval2 && $this->approval3

never becomes true, and activity 4 is never reached.

This doesn’t depend on parallel vs sequential, but parallel often makes these timing issues more visible.

---

3. Verify the await() condition actually becomes true

WorkflowStub::await() is purely “wait until a condition closure returns truthy, then continue”.

Your condition:

fn () => $this->approval2 && $this->approval3

is perfectly valid. But I’d still log inside the signal methods to be sure the workflow state is what you think:

#[SignalMethod]
public function setApproval2($approval2)
{
    Log::info('Signal: setApproval2', ['value' => $approval2]);
    $this->approval2 = $approval2;
}

#[SignalMethod]
public function setApproval3($approval3)
{
    Log::info('Signal: setApproval3', ['value' => $approval3]);
    $this->approval3 = $approval3;
}

If those logs appear but the workflow never leaves the await(), it almost always means the workflow job that should replay history + re-evaluate the callback is never being executed (back to point #1).

---

4. A minimal “known-good” version

If you want a reference, this is a fully fine pattern:

use Workflow\ActivityStub;
use Workflow\SignalMethod;
use Workflow\Workflow;
use Workflow\WorkflowStub;

class MyWorkflow extends Workflow
{
    protected bool $approval1 = false;
    protected bool $approval2 = false;
    protected bool $approval3 = false;
    protected bool $approval4 = false;

    #[SignalMethod]
    public function setApproval1(bool $value): void
    {
        $this->approval1 = $value;
    }

    #[SignalMethod]
    public function setApproval2(bool $value): void
    {
        $this->approval2 = $value;
    }

    #[SignalMethod]
    public function setApproval3(bool $value): void
    {
        $this->approval3 = $value;
    }

    #[SignalMethod]
    public function setApproval4(bool $value): void
    {
        $this->approval4 = $value;
    }

    public function execute()
    {
        yield ActivityStub::make(CreateApprovalRequest1::class);

        yield WorkflowStub::await(fn () => $this->approval1);

        // 2 & 3 in parallel
        yield ActivityStub::all([
            ActivityStub::make(CreateApprovalRequest2::class),
            ActivityStub::make(CreateApprovalRequest3::class),
        ]);

        // wait for both signals
        yield WorkflowStub::await(fn () => $this->approval2 && $this->approval3);

        yield ActivityStub::make(CreateApprovalRequest4::class);

        yield WorkflowStub::await(fn () => $this->approval4);

        return 'success';
    }
}

If this exact pattern doesn’t advance to activity 4 in your app, I’d inspect:

• Waterline / DB to see the workflow status (likely stuck in WorkflowWaitingStatus).
• Queue workers and their queues/connections.
• That the signals are all sent to the same workflowId.

---

TL;DR

• Yes, “run 2 & 3 in parallel → then await() approval2 && approval3 → run 4” is a supported pattern.
• Your original idea is sound; your sequential workaround is just masking whatever’s preventing the workflow from resuming / the condition from becoming truthy.
• If you want, you can paste your Livewire component code + how you start the workflow, and I can point at exactly where the wiring likely goes wrong.

[chipotlegroove]

As an additional question, is it possible to extend the pattern to this?

// 2 & 4 in parallel, 3 sequential
yield ActivityStub::all([
    ActivityStub::async(fn () => [
        yield ActivityStub::make(CreateApprovalRequest2::class),
        //2 and 4 start at the same time, 3 must wait until 2 is approved.
        yield ActivityStub::make(CreateApprovalRequest3::class),
    ]),
    ActivityStub::make(CreateApprovalRequest4::class),
]);

// wait for both signals
yield WorkflowStub::await(fn () => $this->approval3 && $this->approval4);

As I read in the documentation I can't use the await method inside an activity (I still tried and failed :P). So what are the alternatives?
Or would it be better to move on to using child workflows?

[rmcdaniel]

@chipotlegroove I just recreated a basic livewire app and tested out the exact workflow you provided and it worked both ways, sequentially first, and then I changed out the commented lines and had it run in parallel and it also worked there too. I tried clicking each button and waiting for the result and then I tried just clicking the buttons as fast as I can to see if there was a race condition and both ways worked fine. In all cases the workflow completely successfully. I'm wondering if you could double check things again to make sure there wasn't anything that was missed?

As for your second question, that wouldn't work the way you want it to. The async method only waits for activity completion, not signals and you are correct that you can't use await inside of async. You would need to go to a child workflow, but signaling child workflows is a little tricky at the moment. It's still on the roadmap to be officially supported.

[rmcdaniel]

UPDATE: It turns out I was using an older version 1.0.38 but when I updated to the latest version I did indeed see your exact problem! I'm investigating now. Sorry for not thinking to check that sooner!

[rmcdaniel]

UPDATE: @chipotlegroove I have fixed this issue. I have also added your exact scenario as a test case to make sure it won't break again in the future. I have released 1.0.43 with the fix. I have also tested the fix with that previous livewire I reproduced your issue with and I confirmed that it is now fixed. If you still have issues feel free to open an issue. Thanks for your patience and your help with fixing this issue!

[chipotlegroove]

Hey rmcdaniel, thanks for the quick update! Now it works perfectly :)

As for signaling a child workflow, what would be the recommended way of doing so right now? I initially thought of storing the ID's of the children workflow as variables and having them as query methods to be able to signal them from outside sources. I haven't tried this out yet, but is there conceptually anything wrong with this approach?

[rmcdaniel]

@chipotlegroove I actually went ahead and worked on it over the weekend for you! Take a look at https://laravel-workflow.com/docs/features/child-workflows#signaling-child-workflows and hopefully it will give you what you need. Let me know if you have any specific questions.

[chipotlegroove]

Oh wow that's so incredibly kind of you! Thank you very much!