---
title: "Comment by StackShortlist on \"Building Production-Ready React Data Flows with tanstack-fetch and TanStack Query\" | Hashnode"
description: "The five concurrent 401s example is the right way to explain shared refresh. With rotating refresh tokens, the second parallel /auth/refresh call can invalidate"
url: "https://hashnode.com/posts/building-production-ready-react-data-flows-with-tanstack-fetch-and-tanstack-query/6ad315b4a88e1f774db3a8e7/comment/6ad32d1606e54e9091d38d66"
---

[Discussion](https://hashnode.com/posts/building-production-ready-react-data-flows-with-tanstack-fetch-and-tanstack-query/6ad315b4a88e1f774db3a8e7)

Comment [Building Production-Ready React Data Flows with tanstack-fetch and TanStack Query](https://hashnode.com/posts/building-production-ready-react-data-flows-with-tanstack-fetch-and-tanstack-query/6ad315b4a88e1f774db3a8e7)

[Oct 17](https://hashnode.com/posts/building-production-ready-react-data-flows-with-tanstack-fetch-and-tanstack-query/6ad315b4a88e1f774db3a8e7/comment/6ad32d1606e54e9091d38d66)

The five concurrent 401s example is the right way to explain shared refresh. With rotating refresh tokens, the second parallel /auth/refresh call can invalidate the first one's new token and log the user out for no visible reason. The 401 vs 403 table is useful too. Refreshing on a 403 is a common bug that turns a permissions problem into an endless refresh loop.

[mohammad garmabi](https://hashnode.com/@garmabi07)

[Oct 17](https://hashnode.com/posts/building-production-ready-react-data-flows-with-tanstack-fetch-and-tanstack-query/6ad315b4a88e1f774db3a8e7/comment/6ad32d1606e54e9091d38d66#reply-6ad33fdf9dbd8aaffd04582a)

Exactly! That’s why I wanted to handle refresh logic at the HTTP client level rather than repeat it across individual queries. A shared refresh mechanism prevents parallel refresh requests, and keeping `401` and `403` separate avoids unnecessary refresh loops. Thanks for pointing that out!