Failure to deduplicate network requests

[roel-de-jong-iqvia]

Which @ngneat/query-* package(s) are the source of the bug?

query

Is this a regression?

Yes

Description

Given

There are multiple components which "use" a query a single time (take(1))

When

• a query is inactive, and has no observers,
• the query is invalidated twice by (pressing the invalidate button twice)
• there is an event which triggers a query in multiple components (also triggered by invalidate button),

Then

Expected: a single network request is initiated
Actual: It appears requests are not de-duplicated, and the network tab shows multiple canceled queries.

When I continuously observe the query, only a single network request is fired.

Please provide a link to a minimal reproduction of the bug

https://stackblitz.com/~/github.com/roel-de-jong-iqvia/request_deduplication

Please provide the exception or error you saw

No response

Please provide the environment you discovered this bug in

No response

Anything else?

No response

Do you want to create a pull request?

Yes

[NetanelBasal]

I'm not sure what you mean, so PR is welcome.

[roel-de-jong-iqvia]

Hi, thanks for your response.

Basically, I am seeing multiple canceled network requests in the network tab of chrome when using a query in multiple places at the same time. (see stackblitz).

I am not 100% sure what the expected behavior should be. But I think it shouldn't happen that there are multiple concurrent network requests for a single query.

I am willing to create to try to fix this, but I prefer to both agree first that this is in fact a bug.

[NetanelBasal]

Multiple queries with the same key should produce one request.

[roel-de-jong-iqvia]

The queries in my example have the same key, but produce multiple requests,

So I guess seeing multiple canceled network requests is an error.
But perhaps thee is something wrong with my example code.

[NetanelBasal]

Can you reproduce on stackblitz, please?

[roel-de-jong-iqvia]

Ah I mixed up code sandbox and stackblitz.

I have reproduced on stackblitz (https://stackblitz.com/~/github.com/roel-de-jong-iqvia/request_deduplication)

The canceled network requests appear the second time you press the "invalidate" button.

[NetanelBasal]

it doesn't load

[roel-de-jong-iqvia]

Works in my browser.

Press the "invalidate query" button.

Second time you press the button there are multiple canceled requests

(Perhaps it wasn't working at first because it requires changes to be pushed to the github repository)

[NetanelBasal]

Seems like the issue is in take(1).

    this.characters$ = this.event.pipe(
      switchMap(() => this.queryService.character$("joehoe"))
    );

This works

[NetanelBasal]

btw why do you use take 1?

[roel-de-jong-iqvia]

Indeed, I also noticed this:

When I continuously observe the query, only a single network request is fired.

btw why do you use take 1?

In the minimal reproduction I posted it admittedly does not make a lot of sense.

However, in our project we are migrating from Akita stores to Tanstack Query.

In response to an Akita store change, I need to calculate / derive some state from the Tanstack query data,
Originally, the code which performed the calculation was synchronous. However, fetching of query data is of course by nature asynchronous. To mimic the synchronous nature of the original code, I opted to take only the first emitted value.

I can remove the take 1 and workaround it, but it seems to me having promise-like behavior (where we are only interested in a single value emitted by the query) should work in the sense that no duplicate requests are made.

Without having studied the library code I suspect some query context is lost when all query observers unsubscribe?

[NetanelBasal]

If you only need to get the data once you can use ensureQueryData or getQueryData.

https://tanstack.com/query/latest/docs/reference/QueryClient#queryclientgetquerydata
https://tanstack.com/query/latest/docs/reference/QueryClient#queryclientensurequerydata

[roel-de-jong-iqvia]

Hi, using ensureQueryData works.

However, I do think that injectQuery(.).result$ is a leaking abstraction in the sense that if you want to get the data once, you shouldn't use it. Neither do I know how we could enforce the currently implicit contract that the user shouldn't pipe through take(.).

I have written functions which calculate derived state based on the tanstack query state. injectQuery(.).result$ returns an observable with a different data structure than ensureQueryData. In practice this means that I have to abstract over the case where a query is observed continuously, or just once. Basically you want to postpone that decision and leave it to the API consumer.

Is there a technical reason why piping the query observable through take(.) doesn't work?

[roel-de-jong-iqvia]

I can take a look on sunday to see if I can fix this.

If I cannot fix this, I will create a PR to update the documentation with a warning.

[roel-de-jong-iqvia]

I found the root cause of the problem.

In both the example and my project I used the filterSuccessResult operator. I wrongly assumed that this operator would return the latest fresh (non-stale) result. However, the first emission of a query result might actually be stale. This can happen for example when a component starts observing the query after (1) the initial fetch is completed and (2) after it has been invalidated.

Because I only took the first emission with take(1), this caused the refetch of the stale query to appear as cancelled in the Chrome dev tools when the observer was torn down.

I solved the issue by replacing the use of the filterSuccessResult operator with the following custom operator:

export function filterFreshResult<T>(): OperatorFunction<
    QueryObserverResult<T>,
    QueryObserverSuccessResult<T>
> {
    return filter((result): result is QueryObserverSuccessResult<T> => result.isSuccess && !result.isStale);
}

This makes the use of for example take(1) viable.