What causes "yuanbao: sign token error code=%d" in chenhg5/cc-connect?

Map the code value to the yuanbao API's documented error table to identify the business failure.

yuanbao: sign token error code=%d

Error message

yuanbao: sign token error code=%d

What it means

The sign-token API returned a parseable envelope whose business code was not 0 (and not the retryable 10099 within the retry budget). fetchToken returns this error immediately — unlike transport errors, business-code failures are not retried. The numeric code is the upstream service's own error identifier.

Source

Thrown at platform/yuanbao/sign.go:182

		var result struct {
			Code int `json:"code"`
			Data *struct {
				Token    string `json:"token"`
				BotID    string `json:"bot_id"`
				Duration int    `json:"duration"`
				Product  string `json:"product"`
				Source   string `json:"source"`
			} `json:"data"`
		}
		if err := json.Unmarshal(respBody, &result); err != nil {
			lastErr = fmt.Errorf("yuanbao: parse response: %w", err)
			continue
		}
		if result.Code == 10099 && attempt < maxRetries {
			continue
		}
		if result.Code != 0 {
			return nil, fmt.Errorf("yuanbao: sign token error code=%d", result.Code)
		}
		if result.Data == nil {
			return nil, fmt.Errorf("yuanbao: sign token response missing data")
		}
		return &tokenData{
			token: result.Data.Token, botID: result.Data.BotID,
			duration: result.Data.Duration, product: result.Data.Product,
			source: result.Data.Source,
		}, nil
	}
	return nil, lastErr
}

// VerifyCredentials probes the sign-token API with app_key/app_secret and
// returns the bot_id on success. Used by `cc-connect yuanbao setup` so users
// see a clear error before the platform starts retrying on a background loop.
func VerifyCredentials(appKey, appSecret, apiDomain, routeEnv string) (botID string, err error) {
	if strings.TrimSpace(appKey) == "" || strings.TrimSpace(appSecret) == "" {

View on GitHub (pinned to 4000b2338a)

Solutions

Map the code value to the yuanbao API's documented error table to identify the business failure.
Re-verify bot_token credentials with `cc-connect yuanbao setup`; regenerate app_key/app_secret if revoked.
If the code is 10099 repeatedly, the service is throttling/challenging — wait longer between attempts or check account status.
Fix the config value and restart the daemon; this error is terminal for the token fetch.

Example fix

// before
bot_token = "old_app_key:old_secret"
// after
bot_token = "new_app_key:new_secret"

Defensive patterns

Strategy: try-catch

Validate before calling

botID, err := VerifyCredentials(appKey, appSecret, apiDomain, routeEnv)
if err != nil { failFast("yuanbao credentials invalid: " + err.Error()) }

Try / catch

if err != nil && strings.Contains(err.Error(), "sign token error code=") {
    code := parseCode(err)
    switch code {
    case 10099: backoffAndRetry()
    default: alertAndStop()
    }
}

Prevention

Validate credentials at startup with `cc-connect yuanbao setup`, not lazily in background loops
Keep a documented mapping of upstream business codes
Alert on non-zero codes instead of hot-looping retries

When it happens

Trigger: result.Code != 0 after a successful 200 response during fetchToken — e.g. invalid credentials, expired/revoked app_key, account quota exceeded, or code 10099 persisting after maxRetries attempts.

Common situations: Rotated or mistyped app_secret in bot_token, account disabled on the yuanbao side, persistent 10099 (throttling/auth-challenge) that outlives the retry budget.

Related errors

AI-assisted analysis of chenhg5/cc-connect@4000b2338a (2026-09-06). Data as JSON: /api/errors/3401c41970d1d401. Report an issue: GitHub.