For some reason in some circumstances this code doesn't work as expected

[RIP21]

For some reason, safe me query is not getting re-executed. Organization me query always gets re-executed.

Insanely weird behaviour. If I login, and then trigger the code that calls these lines on the screenshot, it is not working.
If I already logged in and refresh the page and do exactly the same on the same page (urql cache state is exactly the same as after login, from logged out page and getting redirected to that same page) it doesn't.

It's happening in Next.js and it's happening in non-suspended mode (suspense: false) as suspense is broken with URQL and Next.js in production and had to disable it as if Next.js suspended routes are conflicting with URQL suspension. (old mode, not app dir)

Don't know whom to blame, but URQL feels VERY unstable. At least in v4 :(

It's with graphcache enabled, and in dev mode with devtools extension.

I'll test a production build this evening (CEST time) and see how it behaves on production, but yeah, super annoying...

[kitten]

I don't really have enough details to give a clear answer here, but reexecute calls are inherently UI concerns

Those are designed to behave more heuristically. Instead, it seems to me like you're trying to do two imperative things at once.I could be wrong, but have you checked whether the push is unmounting the query that isn't being reexecuted?

Maybe add a debugExchange and check for teardowns for the relevant query

[RIP21]

toPromise call actually updates the cache as UI proceeds to rerender and show expected result.

So, TBH I have no idea why rexecute from useQuery behaves any differently (I haven't looked into its implementation recently, but I expect it to be pretty much the same thing, maybe without toPromise (probably in suspense mode it uses promise tho).

[kitten]

probably in suspense mode it uses promise tho

React Suspense does use promises, but the implementation is entirely different, as the characeristics of a suspending component is different.

I have no idea why rexecute from useQuery behaves any differently

I think something is missing here still. It's practically not possible for executeQuery not to work here, unless you're unmounting the useQuery hook's component or interrupting the request otherwise due to the push, as I've previously theorised.

toPromise call actually updates the cache as UI proceeds to rerender and show expected result.

This makes me think that the result is somehow getting lost. However, this can only happen when the operation is triggered as the result comes in and toPromise receives it.

Basically, I've got the debugging steps above for you, but with the current information, this isn't really making sense, and my biggest suspicion is that the logs above, or some other description of this isn't accurate. Sorry! 😅

It's hard for me to reconcile the described behaviour here without details. I'm not denying that there may be a bug in here. But the problem is that the descriptions here of the behaviour don't add up for me, and additionally, I'm lacking enough information. On top of that, I still can't rule out that there's additional meddling in either UI code (or otherwise) that may changing or introducing some of the buggy behaviour here

[RIP21]

@kitten once I'm back from vacation I'll try my best to reread it all and try to narrow it down. If no clear indicators, then, well, I'm always open to a screen share call to try to boil it down in real time.

It's just, I love URQL (especially since you're insanely responsive usually), but hate in the same time, as its reactive nature makes it quite hard to adopt if you do that on something already quite big. If you use it from the day one, it's rather smooth ride.

Another question, is there a unit test or e2e test somewhere in the codebase of urql where I can see all possible state transitions of a query?

For instance, failed query with error, apparently may have a stale to be true, despite operation is finished and not in progress of refetching (network call finished already). I expect fetching to be mostly first load and stale to be reexecute in procees. Either failed or successful query. In case of failed, I don't expect it to ever be stale, as error response is always a cache miss so fetching should be getting into true in case of reexecution up until first successful result comes in.
Afterwards tho, it will depend on what kind of rexecute you do, it it's network-only I assume it invalidates successful result?

Having a table or sort of state machine of all the possible states would be super helpful.

Simplified, like, no partial response is possible.(tbf all of the queries and mutations we do are 1 query and never multiple, and aren't streamed etc, and I expect 98% of urql users are the same, so lots of the capabilites of urql and so the possible states are not relevant for us)

And complicated one, with defer, live, partial results etc.

[kitten]

Another question, is there a unit test or e2e test somewhere in the codebase of urql where I can see all possible state transitions of a query?
Having a table or sort of state machine of all the possible states would be super helpful.

I hear this a lot, but to put it short, every single state is possible, and every single transition is possible:

• data can be set after a result
• fetching may or may not become true; depends on if:
  • how bindings choose to implement and update it, as it's a UI/binding-only flag
  • if the result is cached i.e. available synchronously
• stale can be:
  • initially true if a network request will be started but request is ongoing
  • can become true if an operation starts for the same result
• error & data:
  • can be independently set to value or null
  • data can of course be partial, if graphQLErrors are present
  • data is allowed to be present even if any error is set, to allow exchanges / custom exchanges to pass it
• operations is guaranteed if fetching: false tbf, but that's a detail that's not worth typing
• any value may change or persist during fetching: true/stale: true as bindings will update selectively and keep their last state alive
  • again: this is up to bindings

i.e. any state transition and combination is legal and has a corresponding use-case.

I expect fetching to be mostly first load and stale to be reexecute in procees.

That's basially the case — except, bindings provide fetching, but for all intents and purposes that's the same, except there's no concept of "initial" and I'd recommend not to rely on that assumption too much. fetching will and can become true whenever inputs change and a new operations result source is used.

For instance, failed query with error, apparently may have a stale to be true, despite operation is finished and not in progress of refetching (network call finished already).

Yes, but stale just tells you that there's new data coming. It doesn't mean you have to ignore the error, unless it concerns your UI.

In case of failed, I don't expect it to ever be stale

Again, stale just says a new operation is in progress. That doesn't mean that failures stop requests. This is because it's not illegal for an exchange to cache errors.

Afterwards tho, it will depend on what kind of rexecute you do, it it's network-only I assume it invalidates successful result?

Yes, issuing network-only is defined to skip any cache. This means that it'll always result in an immediate request and your bindings will receive a stale: true update in the meantime.

Simplified, like, no partial response is possible.

This is an easy trap in GraphQL to fall into.
Partial results are important and by definition GraphQL can always deliver partial results at nullable fields 😅

and so the possible states are not relevant for us

The beauty of all of these states is that you can ignore them as needed though. stale is irrelevant if you don't use it. It's by design safe to ignore, if you know you don't need to know whether a new result is coming.

Similarly, you don't have to handle partial results. If you for instance use TypeScript's typegen, in most cases, you'd of course choose to let the UI handle and interpret nullish values without accounting for errors.

[RIP21]

Thanks for such a good response.

This is an easy trap in GraphQL to fall into.
Partial results are important and by definition GraphQL can always deliver partial results at nullable fields 😅

I know I know :) I'm talking mostly that we have only one root query, so it's not that we're going to handle multiple of them quite often. I know all the nuances of GraphQL, just don't want to overcomplicate things :) But it seems it's not that simple if it comes to GQL clients :P

[RIP21]

toPromise call actually updates the cache as UI proceeds to rerender and show expected result.

This is stopped working. Lol.

[RIP21]

How do bindings behave when a client gets changed (recreated)? Will they set fetching or stale while "refetching"?

[RIP21]

Aaaand, nothing works at this point. Killing (recreating) the urql client on login to safe also freezes the tab in the production build...

I guess I'll have to rewrite everything back to Apollo and name it a day.

[frederikhors]

Can you please create a minimum reproduction to further investigate? @RIP21 ?

[RIP21]

Can you please create a minimum reproduction to further investigate? @RIP21 ?

Sadly that would take more time than rewriting it to Apollo. And I doubt I'll manage to reproduce that on a smaller case.

So, I would rather refactor it back to Apollo, and then, after we redesign our GraphQL in a way, there is no need to reset cache as much, so it's needed only on logout, I'll probably try to use URQL again. Unless we move to Redux Toolkit Query and name it a day as it's stupid and simple and ultra reliable :D

Thanks for all the help guys, but I need to ship stuff now ASAP, it already took a 2 weeks extra due to this bug/problem/misuse, which messed up lots of things, and I cannot try to chew through it any longer.