Dear Jack Kleeman, HUGE thank you! This is a major breakthru!!! Number of SDKs and this Xstate mapping tells me Restate is the real deal.

Anything remotely similar to this, but very basic remapping is here, same thing you built here properly: https://youtu.be/GpbOkDjpeYU?t=1631

I tried to somehow make the Temporal click with NextJS > therefore and Xstate: https://github.com/temporalio/samples-typescript/issues/97

I implemented xstate behind the API call that saves snapshot to Postgres, it works but very basic stuff. With your mapping and power of Restate and Xstate now the possiblities are endless. Restate Cloud offer seems attractive.

====

Question:

When will the library be published on NPM so I can try it following the examples you created and try to push it more.

Ah, it is published here: https://www.npmjs.com/package/@restatedev/xstate

But you did some updates in the meantime and they are not on NPM. Will this pipeline be placed so that this starts to grow.

I am crusing very difficult tasks with Xstate on the frontend and basic backend, but to be able to do it in a "durable" way is really next level stuff.

EDIT: I can just use "public_api.js"... ma bad :). All works, testing now..

EDIT2: I literally cant believe this exists. Biggest fan!

hi! I am so so glad to see your excitement about this. youre right there are some improvements since 0.0.1, let me do a release and the pipeline will run :)

Thank you for pushing the new version.

In this early stage, it would be really valuable to see the full list of tasks that need to be done before the lib reaches version 1.0, just by putting "# Road to 1.0" in README.md and just listing all the tasks that remain to be done.

This will bring clarity and get people involved. I might contribute too if capable to pinch in, but I need a list of clear targets.

You envisioned the solution, it works on the version 0.0.1. When it comes to 1.0 it will move mountains on the shoulders of Restate.

What sort of things would you like to see in 1.0? For us, we need to see real world usage before solidifying the featureset and offering a backwards compatibility promise, etc

I will definitely try this stuff in production on non-critical stuff to check how it is working.

I would need a bit of time to dig into this deeply and report back. Give me couple of days please and I will post my feedback.

edit: i am also the milanbgd011 account :)

I got a bit of time, not still digging deep enough unfortunately because of time.

But all works out of the box zero problems:

invoke
entry
exit
after
on
assign
...

Even remembers the "after" trigger, but when it exists the state where after was initiated then it does not work.

Even if I try to get it again to the state where the "pending AFTER:{} needs to fire" it will reject this "AFTER:{}" because it seems that each state has unique "UUID" which guarantees that the "after" will be executed if that unique ID of the current state is the same, otherwise it will be discarded.

Which means that this "pending" after will never accidentally trigger if we end up in the same state, it simply does not belong to that state unique ID. >>> Received now cancelled event 447f3f3a-61e9-4f54-b8e6-9b1d6bea4994.xstate.after.10000

[restate] [auth/send][inv_1h3VdnA6H65X5hvfJibdxkttFWETR00te9][2024-10-19T23:28:02.235Z] INFO:  Received now cancelled event 447f3f3a-61e9-4f54-b8e6-9b1d6bea4994.xstate.after.10000.client.authorizing for target {
  id: 'xyy',
  sessionId: '447f3f3a-61e9-4f54-b8e6-9b1d6bea4994',
  _parent: { id: 'fakeRoot', sessionId: 'fakeRoot' }
}

I tried parallel states, works perfectly.

Also tried versioning the machine, like I leave machine in some "invoke" state to wait for 30 seconds, I stop the service, change the machine to go to "stopped" instead of "idle" state and start service. Restate uses new onDone target and just moves to stopped.

This means that versioning the machines is a piece of cake. You just say what you want to happend with users that are in state that is being removed or rewired and anyone in that state will get new path to go to from that point.

In your example you demonstrated that sendTo along with delay also works. Nesting machines works.

            actions: sendTo(
              ({ self }) => self._parent!,
              { type: "TOKEN" },
              { delay: 1000 }
            ),

====

OMG! What have you built here?! This thing can crush every single task no problem :)

KUDOS! Not a single problem, glitch or weird behaviour. ♥️♥️♥️♥️♥️♥️

This thing goes to production instantly (for non-critical stuff until I am 100% sure no problems will occur).

====

I am just wandering is there anything not covered in here. I mean should we make a list of xstate keys available and then check on/off if it works or not in README.md. This is unclear to me currently.

Thank you! What lovely feedback to receive and I am glad you are trying your hardest to break it - definitely keep trying and if you succeed, I will make sure it gets fixed :D

I think we are missing callback actors, observable actors and possibly transition actors. In practice callback is very similar to promise, observable im not sure really makes sense in a serverless/backend context, but you could certainly make rpcs to the restate ingress from some long-running process with an observable streams. transition actors, i am not sure if these can ever be async - if they are purely sync, they should work as-is, but if async they need a similar approach to promise actors where we run them in a separate handler. definitely more help identifiying particular use cases that are not covered - this would be hugely valuable

Breaking it will not be easy task I think :) But sure I will try! Thank you for the offer to fix what I find broken!

Neither of three mentioned actors are imporant. Serverless is very important, so observable is just wrong/weird I think.

definitely more help identifiying particular use cases that are not covered - this would be hugely valuable

Do you want me to create PR listing all xstate actions, actors... as a bullet points and then we can check off if they work or not in current version. I can confirm many of them and I can test others one by one when I get time, so we have full 1:1 mapping this Restate/Xstate repo to Xstate V5 and know what is covered and what not. I think visibility of this is key for progress here.

PS. Doing some cool examples and letting David K. Piano like the X post will make this thing visible to all Xstate developers. This is the "marketing channel" perfect to get this off the ground. This is how I found Restate and your repo.

41108

@milanbgd011 that would be fantastic! and any suggestions re examples that perhaps align with what you see as interesting use cases, let me know and I can build them

There is no "contribute.md" so I will just post the addtion that could be added to README.md file to track tasks needed to be done before v1.0 is done and also I scanned the entire Xstate V5 docs and created bullet point structure of docs and then gave it a status. Stuff that I tested got ✅, what we talked that will not be supported for now will be ⛔️ and stuff not tested yet are ❓, finally bullet points that are only documentation will have ℹ️. First, this xstate <> restate mapping needs to be tested what works and what does not, then we move to examples and other stuff I suppose.

It would be good to create "CONTRIBUTING.md" and explain how to contribute to the repo properly. Should you enable that anyone can create Merge Request? Now when I push it says I should fork it, so I stopped because there is no CONTRIBUTING.md file.

I would test one by one when I get some time and send MR updating the status of xstate v5 api that I know it works. If you tested some other part of Xstate V5 API or know that it works, then mark it with ✅ please.

- text below should be added to the bottom of README.md -

Road to 1.0

This list will hold all planned things to be integrated before 1.0 is released.

[ ] users running in production and giving feedback
[ ] 100% xstate api decision, implementation

Xstate V5 API tested to be working in Restate

This segment is 1:1 mapping of structure in Xstate V5 docs, then for each option we have status if specific function works inside Restate which uses Xstate machines under the hood. This segment provides clear visiblity what is missing/not implemented and why.

Important to know is that each state has unique ID, so if we schedule "after" to be done in 30 seconds and the machine exists that state and comes back to that state, the unique ID of the current state will be different, so the "after" that we scheadule will not be executed.

❓ Actors
- ℹ️ Actors (only documentation)
- ℹ️ State machine actors
- ✅ Promise actors
- ⛔️ Transition Actors (fromTransition()) (not planned to be supported for now)
- ⛔️ Callback Actors (fromCallback()) (not planned to be supported for now)
- ⛔️ Observable Actors (fromObservable()) (not planned to be supported for now)
- ❓ Invoke
- ℹ️ How are actors different from actions?
- ℹ️ Lifecycle
- ℹ️ Re-entering
- ❓ The invoke property API
  - ✅ Source (fromPromise())
  - ✅ onDone
  - ✅ onError
  - ❓ onSnapshot
  - ❓ Input
- ✅ Invoking Promises
  - ✅ Promise Rejection
- ⛔️ Invoking Callbacks (fromCallback()) (not planned to be supported for now)
- ⛔️ Invoking Observables (fromObservable()) (not planned to be supported for now)
- ⛔️ Invoking Event Observables (fromEventObservable()) (not planned to be supported for now)
- ⛔️ Invoking Transitions (fromTransition) (not planned to be supported for now)
- ✅ Invoking Machines (createMachine())
- ✅ Sending Responses (sendTo())
- ❓ Multiple Actors
- ℹ️ Testing
- ❓ Referencing Invoked Actors
- ❓ Spawn
- ❓ API
- ❓ Source
- ❓ Lifecycle
- ❓ Stopping an actor
- ❓ Systems
- ❓ Actor registration
- ❓ Actor communication
- ❓ Stopping a system
- ❓ Inspection
- ❓ Inspection events
- ❓ Actor inspection events
- ❓ Event inspection events
- ❓ Snapshot inspection events
❓ State machine actors
- ❓ Promise actors
- ❓ Promise actor capabilities
- ❓ Promise actor logic
- ❓ Promise actor input
- ❓ Promise actor output
- ❓ Promise actor error handling
- ❓ Stopping promise actors
- ⛔️ Transition Actors (not planned to be supported for now)
- ⛔️ Callback Actors (not planned to be supported for now)
- ⛔️ Observable Actors (not planned to be supported for now)
- ❓ Invoke
- ℹ️ How are actors different from actions?
- ℹ️ Lifecycle
- ℹ️ Re-entering
- ✅ The invoke property API
  - ✅ Source
  - ✅ onDone
  - ✅ onError
  - ❓ onSnapshot
  - ❓ Input
- ❓ Invoking Promises
- ❓ Promise Rejection
- ⛔️ Invoking Callbacks (not planned to be supported for now)
- ⛔️ Invoking Observables (not planned to be supported for now)
- ⛔️ Invoking Event Observables (not planned to be supported for now)
- ⛔️ Invoking Transitions (not planned to be supported for now)
- ✅ Invoking Machines
- ✅ Sending Responses
- ❓ Multiple Actors
- ❓ Testing
- ❓ Referencing Invoked Actors
- ❓ Spawn
- ❓ API
- ❓ Source
- ❓ Lifecycle
- ❓ Stopping an actor
- ❓ Systems
- ❓ Actor registration
- ❓ Actor communication
- ❓ Stopping a system
- ❓ Inspection
- ❓ Inspection events
- ❓ Actor inspection events
- ❓ Event inspection events
- ❓ Snapshot inspection events
❓ State machines
- ❓ Setup
- ❓ State
- ❓ State object
- ❓ Accessing state snapshots
- ❓ State value
- ❓ State context
- ❓ State children
- ❓ state.can(eventType)
- ❓ state.hasTag(tag)
- ❓ state.matches(stateValue)
- ❓ state.output
- ❓ state.getMeta()
- ❓ State descriptions
- ❓ Context
- ❓ Initial context
- ❓ Lazy initial context
- ❓ Input
- ❓ Updating context with assign(...)
- ❓ Input
- ❓ Creating actors with input
- ❓ Initial event input🔍
- ❓ Invoking actors with input
- ❓ Spawning actors with input
- ❓ Use-cases
- ❓ Passing new data to an actor
- ❓ Output
- ❓ Output in machine actors
- ❓ Output in promise actors
- ❓ Output and TypeScript
- ❓ Events and transitions
- ❓ Event objects
- ❓ Selecting transitions
- ❓ Self-transitions
- ❓ Transitions between states
- ❓ Parent to child transitions
- ❓ Re-entering
- ❓ Transitions to any state
- ❓ Forbidden transitions
- ❓ Wildcard transitions
- ❓ Partial wildcard transitions
- ❓ Valid wildcard examples
- ❓ Invalid wildcard
- ❓ Multiple transitions in parallel states
- ❓ Other transitions
- ❓ Transition descriptions
- ❓ Shorthands
- ❓ Eventless (always) transitions
- ❓ Eventless transitions and guards
- ❓ Avoid infinite loops
- ❓ When to use
- ❓ Delayed (after) transitions
- ✅ Inlined delays
- ❓ Referenced delays
- ❓ Dynamic delays
- ❓ Lifecycle
- ❓ Actions
- ✅ Entry and exit actions
- ❓ Action objects
- ❓ Dynamic action parameters
- ❓ Inline actions
- ❓ Implementing actions
- ❓ Built-in actions
- ✅ Assign action
- ❓ Raise action
- ✅ Send-to action
- ❓ Send-parent action
- ❓ Enqueue actions
- ❓ Log action
- ❓ Cancel action
- ❓ Stop child action
- ❓ Modeling
- ❓ Guards
- ❓ Multiple guarded transitions
- ❓ Inline guards
- ❓ Guard object
- ❓ Higher-level guards
- ❓ In-state guards
- ❓ Initial states
- ❓ Finite states
- ✅ Initial state
- ❓ State nodes
- ❓ Tags
- ❓ Meta
- ❓ Transitions
- ✅ Targets
- ❓ Identifying state nodes
- ❓ Other state types
- ❓ Modeling states
- ❓ Finite states and TypeScript
- ❓ Finite states cheatsheet
- ❓ Parent states
- ❓ Root state
- ✅ Initial state
- ❓ Transitions on parent states
- ❓ Child final states
- ❓ Modeling
- ✅ Parallel states
- ✅ Final states
- ❓ History states
- ❓ Persistence
- ✅ Persisting state
- ✅ Restoring state
- ❓ Deep persistence
- ❓ Persisting state machine values
- ❓ Event sourcing
- ❓ Tags
- ❓ Event emitter
- ❓ Emitting events from actor logic
- ❓ Emit action creator
- ❓ Event handlers
- ❓ Wildcard event handlers

restatedev / xstate

🤯🤯🤯 OMG! Restate + Xstate library #2

- text below should be added to the bottom of README.md -

Road to 1.0

Xstate V5 API tested to be working in Restate