openclaw - 💡(How to fix) Fix Stale explicit auth.order can collapse profile rotation after update

Bug description

After updating to OpenClaw 2026.5.12, profile rotation for a plugin-harness-backed provider stopped after one surviving profile and immediately fell back to the next model provider.

No secrets or real profile identifiers are included below; profile IDs are generic.

Observed behavior

Given config roughly like:

{
  "auth": {
    "order": {
      "provider-x": [
        "provider-x:profile-old-1",
        "provider-x:profile-2",
        "provider-x:profile-old-3"
      ]
    }
  }
}

and the actual credential/profile store containing:

provider-x:profile-1
provider-x:profile-2
provider-x:profile-3
provider-x:profile-4

OpenClaw resolves the rotation order to only:

provider-x:profile-2

When profile-2 is rate-limited/unusable, OpenClaw does not attempt profile-1, profile-3, or profile-4. It immediately falls through to the model fallback provider.

Expected behavior

If an explicit auth.order[provider] contains missing/stale profile IDs, OpenClaw should probably do one of:

1. Validate/warn/fail during config validate or doctor.
2. Drop stale IDs and merge in valid store profiles.
3. If the explicit order is partially stale, append remaining compatible store profiles.
4. At minimum, surface a clear warning that profile rotation is reduced because configured profiles do not exist in the store.

Expected resolved order would be something like:

provider-x:profile-1
provider-x:profile-2
provider-x:profile-3
provider-x:profile-4

or explicit valid ordered profiles first, then remaining valid store profiles appended.

Impact

This creates a surprising failure mode after upgrades/config migrations:

• stale explicit profile IDs survive in config
• profile store contains valid newer profiles
• resolver treats explicit order as authoritative
• missing profiles are silently filtered
• rotation may collapse to one profile
• provider fallback happens prematurely

This is especially confusing because config validate can pass while the runtime profile order is operationally broken.

Environment

Observed on:

OpenClaw 2026.5.12

Likely area

The behavior appears related to auth profile ordering/resolution:

• explicit auth.order[provider] is selected before store profiles
• missing profiles are filtered
• fallback to store profiles only occurs if all base profiles are missing
• if one stale-order profile remains valid, the remaining store profiles are never considered

Pseudo-example:

configured order:
  profile-old-1, profile-2, profile-old-3

store:
  profile-1, profile-2, profile-3, profile-4

current resolved:
  profile-2

expected safer resolved:
  profile-2, profile-1, profile-3, profile-4

Suggested fix

When explicitOrder is present, resolve it as:

valid explicit profiles + compatible store profiles not already included

Alternatively, doctor/migration should detect and repair stale auth.order entries by comparing them against the active profile store.

A warning would also help:

auth.order.provider-x references missing profiles:
- provider-x:profile-old-1
- provider-x:profile-old-3

Rotation will only use:
- provider-x:profile-2