Possible memory leak when using multiple queries on the same page about urql HOT 7 OPEN

Ok I've now updated the reproduction repo with clearer tests. It wasn't even about using the data from the first query in the second, it leaks with just two awaited queries. With just one query there isn't any leak. Also I added a mock API endpoint under the api routes so that the external service isn't affecting the results.

I also set max_old_space_size to 512MB to see if it changed anything.

Below are the results from the autocannon tests. I'm not that good at decyphering the snapshots yet so that doesn't help me much. Those memory readings are taken from the Chrome debuggers memory view after each test.

# /no-leak

11k requests in 60.04s, 17 MB read
Memory usage: 23.8 MB

# /leak

9k requests in 60.04s, 13.2 MB read
Memory usage: 1201 MB

from urql.

Gotcha! That's awesome. I'll have a look at the memory debugger myself this evening. Typically, I'd assume we've created some kind of promise chain or cycle here 🤔

from urql.

Just to clarify before looking into this because that's an important distinction: Does it never come down and stay stuck at 800MB (I assume MB not Mb?) or does it crash?

If your server doesn't actually rise in usage and/or crash it's not a leak, so just clarifying here.

Also just to point this out, there isn't anything special going on here. If you have just two operations (ie two document + variables combos) then it's more of a question how many concurrent queries are actually run as no memory is retained in the core client, bindings, or exchanges 🤔

from urql.

Yeah sorry I meant MB. I tested it again and when the test was completed memory usage was at ~800MB and then it slightly decreased to ~700MB. No crashes, still works fine at that point when manually checking with browser. Memory usage just stays at ~700MB while I waited for 10 minutes for it to come down.

from urql.

Hm, ok gotcha 👍 That doesn't necessarily sound like a memory leak, but a Chrome debugger memory snapshot could show you what's being retained and what's using that memory.

Generally, it's possible that a combination of GraphQL result data and Vue app tree data is being retained concurrently. But it's hard to tell how much memory that adds up to. Generally, 800MB could be plausible given that the GC may choose to also not activate an aggressive sweep phase when it still has enough heap space left

from urql.

Have you had time to check this one out yet?

from urql.

I can confirm we have the same issue on our project.
Using @urql/vue v1.1.2 with nuxt 3.

Any page/component which has two queries will retain all the setup context of the component in memory and it is never released.

For a while I thought it was not an issue with urql as it is not just urql objects like graphcache, queries and data that are retained but also other objects like router object, unhead object etc... Basically anything in the setup function.

But if I remove the second query, it always fixes the problem, on all of the pages/components.

@kitten Have you had a chance to look at this issue yet ?

from urql.