Fast Refresh infinite loop triggered by Urql GraphQL mutations

[PenguinMan98]

Potentially related to "Dependency tracking is disabled"

Issue Description and Reproduction:

In Next.js 15.1.9 with Turbopack enabled, executing a GraphQL mutation via Urql (approveUserTimeDay) and then opening a drawer component triggers an infinite Fast Refresh loop. The console shows continuous "Fast Refresh rebuilding" messages, making the browser unresponsive. The issue only occurs when both actions happen in sequence: (1) execute the mutation, then (2) open the drawer. Opening the drawer without the mutation, or executing the mutation without opening the drawer, does not trigger the loop. The loop persists even after closing the drawer and continues on the page itself, requiring a full browser refresh to recover.

Investigation Findings:

We systematically eliminated all application-level causes through 12 separate test scenarios. The loop persists even when: all Urql cache invalidations are disabled, mutation response processing is disabled, entity caching is prevented (returning null from cache handlers), the useMutation hook is bypassed (using direct client.mutation() calls), polling hooks are disabled, TanStack store updates are disabled, DataGrid row updates are disabled, and query cache is bypassed with network-only request policy. The mutation execution itself at the Urql exchange level triggers Fast Refresh, even when all application logic is disabled. This indicates the issue occurs at a very low level in Urql's exchange processing (cacheExchange, fetchExchange) or in Fast Refresh's dependency tracking mechanism.

Conclusion and Recommendation:

This appears to be a bug in Fast Refresh or an unexpected interaction between Urql's exchange processing and Next.js/Turbopack's Fast Refresh mechanism. Fast Refresh is misinterpreting Urql's mutation execution as a file change, triggering continuous rebuilds. Since the issue occurs even when all application-level logic is disabled and the mutation is executed via direct client calls, this points to a framework-level bug rather than application code. This may be related to other dependency tracking and invalidation issues reported in the Turbopack Error Report discussions.
timecardinvestigation-bug-report.txt