Is there a way to access to event.input in invoke's onDone?

[gkiely]

Is there a way to get the event input that was called prior to invoking in a state in an onDone action.

Currently when accessing the onDone it shows:
{ type : "xstate.done.actor.0.output.loading", output: [] }

But there are times when I would like to see the input. Currently that requires that I save it to the context which is cumbersome when I just want to read the value once.

I can set up code if it's not clear what I'm asking.

[davidkpiano]

It's clear, thank you for the information. Just like a function doesn't automatically return its arguments along with its return value, you must explicitly include that input somewhere.

For example, in onDone, you can include it in the output:

const logic = fromPromise(async ({ input }) => {
  // ...

  return {
    result: [/* ... */],
    input
  }
});

Would that work for your use-case?

[gkiely]

It works ok and storing the value in context also works ok, it just adds a little complexity. If the input variable in the function is unused it is extraneous code, and the context approach requires state management.

In a JS context this would be like a promise that I have awaited and then once it has returned I can access the input variable in scope.

Something like invokedEvent or srcEvent would be handy in onDone and onError, I seem to run into it semi-regularly.

[Andarist]

It would have negative memory implications though - we'd have to keep it around just because u might need it later on (and we don't know if you do). This also means we'd have to keep it in the persisted state (because it could be needed after rehydration).

[gkiely]

It would be reclaimed as soon as you move out of the current state and/or if onDone or onError has been executed, yes?
I understand that it would need to be persisted for the invocation restart, if the invocation is in progress.

[Andarist]

Yes, to both. Not all actors have to complete though - we never know that upfront. Imagine a file upload actor that receives a File as part of the input. It wouldn't be best to hold to those megabytes just because you might want to use it later. This is up to the developer to decide. The consequences of assigning to context are obvious whereas it's not obvious for the developer to know what kind of data we are keeping around in the background if they don't have immediate access to it somewhere.

[gkiely]

Ok, sounds like this is not possible then given the constraints.