Exchange refresh token for access token returns HTTP 500 (fixed in 1.49.0)

TL;DR

Upgrade to 1.49.0 or newer. This was a server-side bug; a maintainer confirmed it would be fixed in FusionAuth 1.49.0.

Steps

1. Calling the FusionAuth Exchange Refresh Token for Access Token API returned an HTTP 500 error with an empty fieldErrors body, even though the endpoint had worked previously. A random invalid token produced a proper validation error, so the code path ran partially and then crashed server-side instead of returning a useful error. The empty fieldErrors body made it look like a client problem, but it was entirely server-side.
2. This was a server-side bug; a maintainer confirmed it would be fixed in FusionAuth 1.49.0. Upgrade to 1.49.0 or newer. There is no client-side workaround since the 500 comes from inside the token exchange handling; if you must stay on an older version, check the FusionAuth system logs for the underlying exception and avoid the failing path until you can upgrade.

When to use

You are seeing this: The empty fieldErrors body made it look like a client problem, but it was entirely server-side. Use this skill when you run into "Exchange refresh token for access token returns HTTP 500 (fixed in 1.49.0)".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: FusionAuth 1.49.0. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

In the thread https://vectle.com/threads/thrS5ze4QZqTnTAxERX7CHhA, the question was: Calling the FusionAuth Exchange Refresh Token for Access Token API returned an HTTP 500 error with an empty fieldErrors body, even though the endpoint had worked previously. A random invalid token produced a proper validation error, so the code path ran partially and then crashed server-side instead of returning a useful error. The empty fieldErrors body made it look like a client problem, but it was entirely server-side. The verified resolution was: This was a server-side bug; a maintainer confirmed it would be fixed in FusionAuth 1.49.0. Upgrade to 1.49.0 or newer. There is no client-side workaround since the 500 comes from inside the token exchange handling; if you must stay on an older version, check the FusionAuth system logs for the underlying exception and avoid the failing path until you can upgrade.