bug: loggerLink shows failed query on page load

Provide environment information

  System:
    OS: macOS 12.5.1
    CPU: (8) arm64 Apple M1
    Memory: 499.39 MB / 16.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 16.16.0 - ~/.nvm/versions/node/v16.16.0/bin/node
    Yarn: 1.22.19 - ~/Documents/dev/node_modules/.bin/yarn
    npm: 8.11.0 - ~/.nvm/versions/node/v16.16.0/bin/npm
  Browsers:
    Brave Browser: 103.1.41.100
    Chrome: 104.0.5112.101
    Edge: 105.0.1343.27
    Firefox: 104.0.1
    Safari: 15.6.1
  npmPackages:
    @trpc/client: ^9.27.2 => 9.27.2
    @trpc/next: ^9.27.2 => 9.27.2
    @trpc/react: ^9.27.2 => 9.27.2
    @trpc/server: ^9.27.2 => 9.27.2
    next: 12.2.5 => 12.2.5
    react: 18.2.0 => 18.2.0
    react-query: ^3.39.2 => 3.39.2

Describe the bug

When using loggerLink in a newly scaffolded create-t3-app, it logs a failed query on each page load, followed by a successful query. However only one network request is made.

This only happens in dev, not in prod, even if the loggerLink is active there.

Related issue from create-t3-app: https://github.com/t3-oss/create-t3-app/issues/390

To reproduce

https://github.com/c-ehrlich/loggerlink-bugreport (it’s just a stock create-t3-app@latest)

npm i
npx prisma db push
npm run dev

Open http://localhost:3000, look in the console

Additional information

• No network requests are made on the first, failed query
• Based on stepping through what happens in the debugger and reading some bits of the tRPC source, I think it’s related to how tRPC’s React Query wrapper deals with React 18’s behavior of mounting components twice. An AbortSignal is used to cancel the promise of the query when the component unmounts, and I think the loggerLink is catching this.
• I think this issue might fix it https://github.com/trpc/trpc/issues/2612
• It doesn’t happen with tRPC v10 (or at least not in create-t3-app@next). Not sure why as from my (very limited) understanding of the code, the useQuery and loggerLink behaviors are implemented basically the same.

Screenshots below of v9 (top) and v10 (bottom).

Here’s the stack trace of the failed query:

TRPCClientError: The operation was aborted.
    at Function.from (webpack-internal:///./node_modules/@trpc/client/dist/TRPCClientError-09b8a26b.esm.js:78:14)
    at eval (webpack-internal:///./node_modules/@trpc/client/links/httpBatchLink/dist/trpc-client-links-httpBatchLink.esm.js:209:87)
    at Object.onDone (webpack-internal:///./node_modules/@trpc/client/dist/trpc-client.esm.js:196:13)
    at Object.done (webpack-internal:///./node_modules/@trpc/client/dist/trpc-client.esm.js:110:219)
    at promise.cancel (webpack-internal:///./node_modules/@trpc/client/dist/trpc-client.esm.js:325:17)
    at cancelFn (webpack-internal:///./node_modules/react-query/es/core/retryer.js:118:28)
    at Retryer.cancel (webpack-internal:///./node_modules/react-query/es/core/retryer.js:41:40)
    at Query.removeObserver (webpack-internal:///./node_modules/react-query/es/core/query.js:209:26)
    at QueryObserver.destroy (webpack-internal:///./node_modules/react-query/es/core/queryObserver.js:76:23)
    at QueryObserver.onUnsubscribe (webpack-internal:///./node_modules/react-query/es/core/queryObserver.js:61:12)
    at eval (webpack-internal:///./node_modules/react-query/es/core/subscribable.js:26:13)
    at eval (webpack-internal:///./node_modules/react-query/es/react/useBaseQuery.js:82:7)
    at safelyCallDestroy (webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:22927:5)
    at commitHookEffectListUnmount (webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:23095:11)
    at invokePassiveEffectUnmountInDEV (webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:25202:13)
    at invokeEffectsInDev (webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:27346:11)
    at commitDoubleInvokeEffectsInDEV (webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:27319:7)
    at flushPassiveEffectsImpl (webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:27051:5)
    at flushPassiveEffects (webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:26979:14)
    at eval (webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:26764:9)
    at workLoop (webpack-internal:///./node_modules/scheduler/cjs/scheduler.development.js:266:34)
    at flushWork (webpack-internal:///./node_modules/scheduler/cjs/scheduler.development.js:239:14)
    at MessagePort.performWorkUntilDeadline (webpack-internal:///./node_modules/scheduler/cjs/scheduler.development.js:533:21)

(i’d be up to work on this, but it can probably get fixed much faster by someone more familiar with tRPC/RQ codebases as I haven’t read either before yesterday)

👨‍👧‍👦 Contributing

• 🙋‍♂️ Yes, I’d be down to file a PR fixing this bug!

[sachinraja]

I see this on v10 too with 10.0.0-proxy-alpha.64. This is because passing the React Query abort signal was only added in #2475, which is after 10.0.0-alpha.48 (which c3a@next uses). We also had switched to @tanstack/react-query, where the promise.cancel method we were using was no longer supported so queries were not being aborted on unmount.

I think it’s related to how tRPC’s React Query wrapper deals with React 18’s behavior of mounting components twice

Yes, React Query is aborting the query when the component unmounts like you said. I don’t really see a way to fix this, it’s just React strict mode being React strict mode.

#2612 would definitely mitigate the issue though. That way, you’re only opting into the queries that will be aborted on unmount.

[AlvaroAquijeDiaz]

but using 10.0.0 and alphas may introduce unexpected changes in future releases, right?