Document the cancellation behavior of LocalResource and AsyncDerived

[zstewar1]

Is your feature request related to a problem? Please describe.
When using LocalResource, it's not clear what the sequencing and cancellation behavior is. For example, what happens if one of the dependencies changes faster than the future completes? What if my async fetcher function has side effects?

For example:

async fn a_slow_fetch_operation(ms: u64) -> u64 {
    tokio::time::sleep(Duration::from_millis(ms));
    ms / 2
}

let some_signal = RwSignal::new(10_000);

let res = LocalResource::new(|| async {
    let some_value = a_slow_fetch_operation(some_signal.get()).await;
    store_in_local_storage(some_value);
});

some_signal.set(100);

Here, the second fetch will obviously complete before the first fetch. What I need to know is:

1. What values will the LocalResource.get() take? Will it go straight from None to Some(50), or will the second fetch be delayed until the first one completes? Is there a risk of it going backwards from Some(50) to Some(5000)?
2. What about the side-effects? Could the local-storage value transition from 50 to 5000?
   • Obviously there's no way for LocalResource to guarantee that intermediate side effects of the fetch operation don't get called, what I'm most concerned about is LocalResource making guarantees about stopping async processing of one request before starting the next; that is, guaranteeing that no new side-effects will happen after the next effect starts.

Describe the solution you'd like
I would like the documentation for LocalResource to give a clearer description of how it handles cancellation when signal dependencies change, and to explicitly specify any guarantees it makes about when it will start/stop processing one fetch call relative to other fetch calls.

Describe alternatives you've considered
If LocalResource makes guarantees about the state ordering of its .get() return value, but not about cancelling pending fetch functions, I guess I could use and Effect to handle side effects:

let res = LocalResource::new(|| async {
    a_slow_fetch_operation(some_signal.get()).await
});
Effect::new(move || {
    if  let Some(some_value) = res.get() {
        store_in_local_storage(some_value);
    }
});

[chrisp60]

Kind of seems like the questions below are a summary of what may need to be clarified in docs (feel free to correct)

1. When does the async work start?
2. Are there scenarios where the resource will stop the async work?
3. When do the subscribers that depend on the resource get notified that the async work is completed?
4. Do resources do anything to debounce/batch updates?

Someone more knowledgeable may come in an correct me but AFAIK...

1. ASAP (tick)
2. No (except for panics)
3. ASAP (tick)
4. No

[zstewar1]

It's not just about debouncing and cancellation. I also need to know if LocalResource can result in data races. Like if I have a LocalResource with a dependency and quickly change the dependency several times, have I created a race condition where the final value of the LocalResource depends on which async operation finishes last?

async fn a_slow_fetch_operation(ms: u64) -> u64 {
    tokio::time::sleep(Duration::from_millis(ms));
    ms
}

let some_signal = RwSignal::new(5_000);

let res = LocalResource::new(|| a_slow_fetch_operation(some_signal.get()));

// Suppose these all happen on different Ticks:
some_signal.set(100);
some_signal.set(10_000);
some_signal.set(200);
some_signal.set(3_000);

Once all of these async operations settle, does LocalResource guarantee a final value of 3_000 (the result from the very last value of some_signal?) or does the value depend on the completion order, meaning the final value is potentially 10_000 even though that doesn't correspond to the final value of some_signal?

If the final state is guaranteed to depend on the final value of the input signal, then it would be safe to do side-effects in an Effect::new, since that would also set the side-effect value to the latest value.

This is also why I was asking about serialization of outputs. With that set of some_signal inputs, is LocalResource guaranteed to change 5 times? Or might it change fewer than 5 times, if some async calls take longer to finish? Alternatively, does LocalResource ignore any pending async calls that aren't going to affect the output? Like if I make all of those changes to the value of some_signal before any of them actually complete, will LocalResource potentially transition None -> 100 -> 200 -> 3_000, or will the value from some_signal.set(200) be ignored if I've already triggered the update to some_signal.set(3000), meaning it would only end up seeng None -> 3_000, even if the values from 100 and 200 were available in between?

[chrisp60]

I don't believe it will ever spawn multiple invocations of the fetcher to be polled in parallel. I believe it is literally just a FIFO stream. The Effect will see every change, in the order they occur (keep in mind, it likely sees the None states as well, as it refreshes). The library would have to make some pretty wild assumptions of your intent if it did otherwise. I understand the confusion though, and others know way more about this than I do, so I could be wrong.

If you put a log statement in the effect, what gets logged?

[gbj]

There are a lot of individual questions in these two posts, so I apologize if I miss any nuance.

The behavior for ArcAsyncDerived (and therefore for LocalResource and Resource and all their variants) is fairly straightforward. (It is implemented here, for reference).

Every AsyncDerived has a version field, which is a value that increase by 1 every time the AsyncDerived is triggered to run. The process goes:

1. Create the Future
2. Increment the version to give me this_version
3. .await the Future
4. Check the latest version
5. If this_version is still the latest version, commit the new value to the value of the AsyncDerived and notify dependencies

This means that:

1. The value will not "rewind" due to a race condition in how long the async work takes (i.e., the length of step 3): the value will reflect the latest value to be triggered, not the latest value to resolve
2. None of the Futures that are created will be canceled.

Resources should be used primarily for loading data, and should not have side effects in the async block.

You are 100% correct that you should use an Effect to handle side effects.