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

  1. Parse the leading name from the message: 'InvalidAccessToken'/'InvalidRefreshToken' → re-authenticate via authorize(state); 'FlowControl' → back off and retry with exponential delay.
  2. Verify clientId/clientSecret in AuthConfig against the Teambition app settings.
  3. Ensure refresh tokens are single-use: always store the new refresh token returned by refresh().
  4. 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

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


AI-assisted analysis of justauth/JustAuth@694bbf1b01 (2026-08-14). Data as JSON: /api/errors/9b6bf96e951c1c34. Report an issue: GitHub.