Abort createAsyncThunk before condition promise resolve

[KeisJS]

Hello. I abort thunk before the condition is resolved. But after resolving the condition, the thunk is still executed.

export const sampleThunk = createAsyncThunk('sampleThunk', async () => {
  console.log('do something async');
}, {
  condition: () => new Promise((res) => {
    setTimeout(() => res(true), 1000);
  }),
});

useEffect(() => {
    const sampleThunkAction = dispatch(sampleThunk());

    sampleThunkAction.abort();
  }, [dispatch]);

Is this a bug or feature?

[phryneas]

Calling .abort() just means that the AbortSignal that is passed into your thunk as an argument will be aborted.

We could also check that signal once the thunk itself starts, seeing that condition can be async, that's a good point. @markerikson your thoughts?

[phryneas]

You cannot "stop a thunk at all" - technically. It is an asynchronous function. In JavaScript, we have no way of going into a running function and cancelling it from the outside. All we can do is take an abortSignal and hand it into your thunk payload creator function so you can check if you should abort.

the "abort" event does not occur.

I assume the .abort event already occured - so you would have to check for AbortSignal.aborted.

[KeisJS]

I mean, if call .abort() then condition promise is mutted and semantically thunk treated as aborted at all.
I understood canceling while running. I'm interested in the case with condition promise.
In my case aborted === false, without condition promise aborted === true

[KeisJS]

No ideas? Is this behavior normal? I'm sorry if it's intrusive

[phryneas]

I already said it in my initial post, but let's be clearer:

.abort has to do with AbortSignal.
condition has to do with "should the payloadCreator function be executed?"

These two were completely separate things as condition was always synchronous, so it was not really a thing to call abort while it was running.

We can think about adding this as a new feature, but we just released 1.9 and will need some time to calm down until we get to new features. And even then, a new release is probably months away.

[KeisJS]

Thank you very much for the conversation) I was a little worried before creating XD

I think it's semantically unlikely to do something heavy in the condition, so we don't need to follow up and abort it. But to mute the condition itself, if .abort() was called, makes sense.

I'll calmly wait as long as necessary, we are not going to change the redux toolkit)

p.s: I can give an example when it is useful and consistent in meaning with the example used in the documentation