justauth/JustAuth · error · AuthException
${name}, ${message}
Error message
${name}, ${message} What it means
AuthTeambitionRequest.checkResponse throws AuthException with 'name, message' concatenated from the JSON payload when BOTH `message` and `name` keys are present. Teambition signals errors with an error object containing a machine name (e.g. 'InvalidAccessToken') and a human message; JustAuth joins them into one string. No numeric code is attached.
Source
Thrown at src/main/java/me/zhyd/oauth/request/AuthTeambitionRequest.java:118
this.checkResponse(refreshTokenObject);
return AuthResponse.<AuthToken>builder()
.code(AuthResponseStatus.SUCCESS.getCode())
.data(AuthToken.builder()
.accessToken(refreshTokenObject.getString("access_token"))
.refreshToken(refreshTokenObject.getString("refresh_token"))
.build())
.build();
}
/**
* 检查响应内容是否正确
*
* @param object 请求响应内容
*/
private void checkResponse(JSONObject object) {
if ((object.containsKey("message") && object.containsKey("name"))) {
throw new AuthException(object.getString("name") + ", " + object.getString("message"));
}
}
}
View on GitHub (pinned to 694bbf1b01)
Solutions
- Parse the leading name from the message: 'InvalidAccessToken'/'InvalidRefreshToken' → re-authenticate via authorize(state); 'FlowControl' → back off and retry with exponential delay.
- Verify clientId/clientSecret in AuthConfig against the Teambition app settings.
- Ensure refresh tokens are single-use: always store the new refresh token returned by refresh().
- Wrap calls in retry-with-backoff for FlowControl only, never for credential errors.
Defensive patterns
Strategy: retry
Validate before calling
// validate token freshness before Teambition calls
if (token.getExpireTime() != null && System.currentTimeMillis() > token.getExpireTime() - 60_000L) {
token = teambitionRequest.refresh(token); // refresh proactively
} Try / catch
// retry-with-backoff, but only for rate limiting
for (int i = 0; i < 3; i++) {
try { return request.getUserInfo(token); }
catch (AuthException e) {
String m = String.valueOf(e.getMessage());
if (m.startsWith("FlowControl") && i < 2) { Thread.sleep((1L << i) * 500); continue; }
if (m.startsWith("InvalidAccessToken") || m.startsWith("InvalidRefreshToken")) {
redirect(request.authorize(state));
}
throw e;
}
} Prevention
- Refresh Teambition tokens proactively before expiry rather than reactively.
- Treat refresh tokens as rotating single-use values.
- Wrap Teambition calls in a rate-limit-aware retry decorator.
When it happens
Trigger: Any Teambition API call (access token exchange, user info, refresh) whose response body contains both name and message — typical values: InvalidAccessToken, InvalidRefreshToken, BadRequest, or FlowControl during rate limiting.
Common situations: Expired or revoked Teambition access token (sessions are short-lived); reusing a refresh token after it was already rotated; Teambition client_id/client_secret mismatch; API quota exhausted ('FlowControl' name).
Related errors
- object.getString("error_description") / object.getString("er
- object.getString("msg")
- object.getString("error")
- JSONObject.toJSONString(response)
- data.getString("description")
AI-assisted analysis of justauth/JustAuth@694bbf1b01 (2026-08-14).
Data as JSON: /api/errors/9b6bf96e951c1c34.
Report an issue: GitHub.