Error rules and egress cooldown

Two operator-configurable resilience settings live on Dashboard → Providers → (provider), in the same toolbar as Round Robin, Cache Affinity, and Max Concurrent: per-provider error rules and egress-bucketed 429 cooldown. Add active connections and review their proxy-pool assignments before changing either setting.

Provider error rules

settings.providerErrorRules lets an operator declare error markers for a provider alongside the built-in provider rules. A declared rule is consulted before built-in rules, so it can add a marker for a provider that has none, or override the scope and cooldown of a status code that already matches a generic rule.

Open the Error Rules button on a provider's connections page to add, review, and remove rules. Each rule has:

• status: the HTTP status code from the upstream response (100 to 599).
• match: a plain, case-insensitive substring of the raw upstream error text. This is never a regular expression. The settings API rejects anything that is not a plain string, so a rule can never introduce a ReDoS on the error-classification hot path.
• scope: model, provider, or connection. Matches the same scopes the built-in rules use for fallback locking.
• cooldownMs (optional): overrides the generic exponential backoff ladder.

Example: a provider that returns HTTP 429 with the text daily cap hit when its free tier resets, and the operator wants every connection on that account locked for 10 minutes:

{
  "providerErrorRules": {
    "customprovider": [
      {
        "status": 429,
        "match": "daily cap hit",
        "scope": "connection",
        "cooldownMs": 600000
      }
    ]
  }
}

PATCH /api/settings with that body persists the rule; it applies immediately and again on the next server start. Up to 50 rules total are allowed across all providers.

Declaring a rule for a provider is the opt-in. There is no separate allowlist to widen.

Egress-bucketed 429 cooldown

settings.egressBucketedProviders opts a provider into cooling down every sibling connection that shares the same egress IP when one connection hits a 429. This matters for providers whose upstream quota is bucketed by IP address rather than by account: without it, DurinDoor keeps retrying every sibling connection one at a time until each burns its own guaranteed-to-fail call.

The bucket key is the connection's configured proxy pool in Dashboard → Proxy Pools. Connections routed through the same pool are assumed to share the same egress IP. Connections with no pool configured are never grouped together, since assuming every direct connection shares one host IP does not hold for most deployments.

Toggle Egress-Bucketed 429 on a provider's page to opt it in, or set it directly:

{
  "egressBucketedProviders": ["opencode"]
}

With that setting, if connection A (assigned to proxy pool us-east-1) gets a 429 for opencode, every other opencode connection also assigned to us-east-1 is cooled down for the same window, skipping the reauth-quarantined and already-cooling ones. A sibling on a different pool, or with no pool at all, is left alone.

Verify and recover

Save a narrow rule matching an observed upstream error. Confirm the matching status and cooldown in the provider connection view when that error occurs. Do not use a broad substring that catches unrelated failures.

For egress grouping, inspect proxy-pool assignments before enabling the option. Reusing a pool label is an assumption about shared egress, not a measured public IP. A direct connection is not grouped.

If a rule blocks healthy traffic, remove it in Error Rules. Turn off Egress-Bucketed 429 if your pools do not represent shared quota buckets. Check current connection cooldowns before repeating the request.