# asyncwaiter

> Fail more. Learn more.. Personal engineering blog.

## Posts

- [ReactQuery의 staleTime: 0은 정말 0일까?](https://asyncwaiter.com/2026/10/react-query-stale-time-zero.md): prefetch한 데이터를 hydrate했는데도 dev 모드 30회 실행에서 요청이 60회 찍혔다. 원인을 staleTime 0으로 설명했던 지난 글의 결론은 틀렸다. React Query는 Suspense에서 staleTime을 최소 1,000ms로 올리고, 그 숫자는 React가 fallback 커밋 이후 reveal을 300ms throttle하기 때문에 나온 값이었다. 실험에서는 308ms, 608ms, 908ms 간격으로 노출됐다.
- [렌더링 경계[1]: Server Functions cannot be called during initial render](https://asyncwaiter.com/2026/10/rendering-boundary-server-functions.md): DataDog에 주 3,000건씩 쌓이던 에러를 추적했다. useSuspenseQuery가 커밋 전 렌더 단계에서 queryFn을 실행하고, 그 안에 Server Function이 들어 있던 것이 원인이었다. useQuery로 바꾸라는 조언 대신 use server 파일에서 읽기 함수를 분리해 에러를 0건으로 만들었지만, 같은 샌드박스에서 30회를 측정하자 요청은 60회가 나왔다. 서버와 브라우저의 queryClient가 다르기 때문이었다.

## Posts (English)

- [Is React Query's staleTime: 0 really 0?](https://asyncwaiter.com/en/2026/10/react-query-stale-time-zero.md): I prefetched the data and hydrated it, and 30 runs in dev mode still logged 60 requests. The conclusion from my last post, that staleTime 0 was the cause, was wrong. React Query raises staleTime to a 1,000ms floor in Suspense, and that number exists because React throttles reveals by 300ms after the fallback commit. In my experiment, content was revealed at 308ms, 608ms and 908ms.
- [Rendering Boundaries[1]: Server Functions cannot be called during initial render](https://asyncwaiter.com/en/2026/10/rendering-boundary-server-functions.md): I traced an error that was piling up in DataDog at about 3,000 a week. The cause was that useSuspenseQuery runs queryFn during render, before commit, and a Server Function was sitting inside it. Instead of the advice to switch to useQuery, I pulled the read function out of the use server file and the error went to zero. But when I measured 30 runs in the same sandbox, the requests came back as 60. The server and the browser have different queryClients.