You mark two lines // warning line number, but I think you"re only showing one of the warnings.

At least one of them is telling you that the way you"re accessing new_data here is not reactive:

async fn load_data(count: ReadSignal<i32>, set_count: WriteSignal<i32>) {
    let new_data = move || count() + 1;
    set_count(new_data());
}

This "looks" reactive (you"re doing move || count() + 1) but actions don"t re-run in response to reactive changes, which is why it"s warning you that you"re accessing a value in a reactive way outside a reactive context.

I"m not totally sure what you"re trying to achieve here, or if this is a super simplified version of something else, but it seems like it would be much easier to do something like this:

#[component]
pub fn BlockNumber() -> impl IntoView {
    let (count, set_count) = create_signal(0);
    let (interval, set_interval) = create_signal(500_u64);

    let Pausable { .. } = use_interval_fn(
        move || {
            spawn_local(async move {
                set_count(count.get_untracked() + 1);
            })
        },
        interval,
    );

    view! {
        <p>{move || count()}</p>
    }
}

actions don"t re-run in response to reactive changes, which is why it"s warning you

Ok got it. Using get_untracked()

Could this reactive warning track the span of the caller? That would be a lot of easier to debug.

Sometimes, the source is defined at a third party library. For example, this warning:

How this information could be really meaninful, when is defined at a third party library?

Could this reactive warning track the span of the caller? That would be a lot of easier to debug.

The spans are sometimes broken by closures, because (afaik) you can"t use #[track_caller] on a closure.

Sometimes, the source is defined at a third party library. For example, this warning:

How this information could be really meaninful, when is defined at a third party library?

On the other hand, the warning you post, without any context, looks pretty useful. These are all open source libraries, right? So if it"s giving you a reference for where a signal is defined in another library, you can look and see what that os.

Ultimately this is just a linting and debugging tool that goes away in release mode. It isn"t perfect but it doesn"t need to be... it"s there to surface obviously wrong scenarios, and it works very well helping beginners fix misuses of the API in their own code. It"s always good to reduce false positives when possible but I don"t see a concrete issue here that can be addressed.

Linking to rust-lang/rust#87417