Is invoking a mutation in a queryFn on error considered bad practice?

[cgatian]

Is invoking a mutation within a queryFn considered bad practice?
@TkDodo has commented "fire the mutation from within the queryFn will also work.", so perhaps this is fine?

---

My app is similar to a remote desktop application where you can connect to multiple machines. If the connection becomes severed the server returns an error. When this occurs I want to attempt a reconnection. It's similar to a 401 unauthenticated, but different because I don't want to log the user out, or redirect them to a login screen.

queryFn: () => {
    return api.getResults();   // Could return an error code
}

My first attempt was to try/catch the error within the queryFn and invoke the reconnect.

queryFn: async ({ queryKeys }) => {
  try {
      api.getResults();
  } catch (err) {
      reconnect(queryKeys[2]) // queryKeys[2] has connection info
  }
}

While this worked, I thought it was odd that this query had side effects of performing a reconnection and it may be better deferred to an ErrorBoundary. When I explored using an ErrorBoundary, I updated the queryFn to throw a custom Error, adding the query key to the Error object, so I could properly invoke the reconnect mutation in the ErrorBoundary. This works, but it's making me think I'm overcomplicating the issue.

• Custom ErrorBoundary needs to detect the specific thrown errors.
• Custom ErrorBoundaryneeds to be established somewhere in the component tree. (not a deal breaker)
• I don't have great experience using an ErrorBoundary and I'm worried I might be overlooking something.

If it's OK to invoke a mutation in a queryFn, I think I'd choose that option. However, to me, it still feels odd that the queryFn has this business logic, but perhaps it's the most straightforward approach.

I'd love opinions from the community. Thank you.