Always Guard not Running on Actor Start

[glad mantle]

Hi, I have the following machine definition. I load the following snapshot in an actor and start it. Everything works as expected, except that the guardrails function for the always connection for "Payment Requirement": "Start", is never run. Any idea what might be wrong or how I could debug this?

    const actor = createActor(this.machine, {
      snapshot: {
            "status": "active",
            "output": null,
            "error": null,
            "value": {
                "Data Preparation": {
                    "Intake": {
                        "LawLift": "Received",
                        "Passports": "Received",
                        "Payment Requirement": "Start"
                    }
                }
            },
            "historyValue": {},
            "context": {},
            "children": {}
        }
    });
    actor.start();

[cinder glade]

Where's the guard's definition? Can you share that?

[glad mantle]

@cinder glade Sorry for the late reply, I was on a break. Here is the definition of the guard:

'Express Incorporation OR Payment Full': function ({ context, event }) {
      // Add your guard condition here
      return true;
    }

[cinder glade]

How do you know the guard isn't being run. It returns true every time. So it isn't doing anything right noe now.

[glad mantle]

@cinder glade I put a console.log in the guard and debug breakpoint. Both didn't execute.

[cinder glade]

Ok

[cinder glade]

Have you tried it with an inline guard to see if that makes a difference?

always: {
  guard: ({ context }) => context.temperature > 100,
  target: 'boiling'
}

I doubt it makes a difference, but maybe put the guard before the target?

[glad mantle]

@cinder glade Yes, I did. I implemented both approaches and it did not work. Also, when I run actor.start(), I put a breakpoint in the code and investigate the "actor" variable. When traversing through it, I can clearly find the console.logs in the function definitions, which I defined above, but they simply don't execute. Therefore, it is does not seem to be initialisation issue on my end. 🤔

[cinder glade]

Do you have a link to the a repo by any chance? It's hard to troubleshoot without the code. I'm no expert at XState anyway. Someone else might spot the problem from the code you've shared.

[glad mantle]

pm

[cinder glade]

pm?

not sure what that means.

[glad mantle]

Sorry for the acronym. "pm" is short for personal message. It's a quick way for me to say, that I write you via a personal message for the code sharing. Is that ok?

"dm" would make more sense on Discord 😅

[cinder glade]

Oh. Sure.

[glad mantle]

@cinder glade Here is a minimal reproduceable repository for the problem. Let me know if something is unclear.

https://github.com/access2justice/reproduce-stately-bug

[cinder glade]

I tried to make a sandbox on stackblitz but I'm getting an error. https://stackblitz.com/github/access2justice/reproduce-stately-bug?file=README.md

[glad mantle]

@cinder glade Please query the .../fulfillments path in the browser address bar

[cinder glade]

I was able to get it to work but since I'm mainly a React user, I'm a bit lost. Maybe @vague charm can take a look at it when he gets a chance. Sorry, I couldn't be more help.

[vague charm]

Lots of dependencies here; this is not minimally reproducible

Which state machine has the problem?

[glad mantle]

The only one in the codebase,
./src/fulfillments/state-machines/.../incorporation-llc-sc.xstate.ts

[glad mantle]

@vague charm , I made it a real minimal viable reproduceable repository. Couple of dozen lines of code. Would you mind taking another look?

[vague charm]

Thank you, I will. Same link?

[glad mantle]

@vague charm Yes, there you go: https://github.com/droegier/reproduce-stately-bug/tree/main

[vague charm]

Oh okay, so the reason this doesn't take the always transition is because you're restoring to a specific state, so the always transition doesn't know which event was used to cause a transition.

Imagine if it were:

always: {
  guard: ({ event }) => event.expectedPayload === 42,
  // ...
}

If you're restoring from a persisted snapshot, what should the event be?

One workaround is to just send an event immediately after starting.

To put it another way, you're telling the state machine "hey, you were at this state before"

[glad mantle]

@vague charm Ok, thanks for explaining that.

In my machines, the always transitions with guards, will always merely depend on the context and never the event payload.

Given this, I'm thinking about running a dummy event every time I restore to a specific state and context, in order for any always transitions to be ran, who might have not passed before due to a different context. Does that approach make sense? Any suggestions on a good way to configure this dummy event?

[vague charm]

It does make sense, and I think we should do similar when restoring from a state (cc. @frosty bear) because every state should be preceded by an event, and we don't persist the event anymore on the state