PR #61689: fix(delivery): treat HTTP 4xx errors as permanent in delivery recovery

• Repository: openclaw/openclaw
• Author: EronFan
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/61689

Description (problem / solution / changelog)

Summary

Fixes #61680 - Delivery recovery retries permanent errors (400: message too long) indefinitely on restart.

Problem

HTTP 4xx errors (400, 413) were not recognized as permanent errors by isPermanentDeliveryError(), so entries with these errors were retried indefinitely on every gateway restart (up to MAX_RETRIES=5 per startup cycle).

Example error: "Call to sendMessage failed! (400: Bad Request: message is too long)"

Root Cause

isPermanentDeliveryError() only checked string-pattern allowlists (PERMANENT_ERROR_PATTERNS) but did not detect HTTP status codes in error messages. HTTP 4xx client errors are permanent — the request is malformed and will never succeed on retry.

Fix

Extend isPermanentDeliveryError() in delivery-queue-recovery.ts to detect HTTP 4xx status codes from error messages and treat them as permanent (move to failed/ immediately):

// HTTP 4xx client errors are permanent — the request is malformed and will never
// succeed on retry. Examples: 400 (bad request), 413 (payload too large), 429 (rate limit).
// 5xx errors are transient and should be retried.
if (/\(4\d{2}[^)]*\)/.test(error)) {
  return true;
}

Testing

Added 6 new test cases:

• HTTP 400 Bad Request → moves to failed/ immediately (permanent)
• HTTP 413 Payload Too Large → moves to failed/ immediately (permanent)
• HTTP 500 Internal Server Error → stays in queue for retry (transient)
• HTTP 502/503 → stays in queue (transient)
• Unit tests for isPermanentDeliveryError() with various 4xx/5xx strings

Files Changed

• src/infra/outbound/delivery-queue-recovery.ts
• src/infra/outbound/delivery-queue.recovery.test.ts

Changed files

• src/infra/outbound/delivery-queue-recovery.ts (modified, +10/-1)
• src/infra/outbound/delivery-queue.recovery.test.ts (modified, +75/-0)

PR #61699: fix(delivery): treat HTTP 4xx client errors as permanent in recovery

• Repository: openclaw/openclaw
• Author: kagura-agent
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/61699

Description (problem / solution / changelog)

Problem

On every gateway restart, delivery recovery picks up entries from the delivery queue and retries them — even when the error is permanent (e.g., Telegram's 400: Bad Request: message is too long). This causes the same failed message to be re-sent to the user on every restart, indefinitely.

Fix

Added four new patterns to PERMANENT_ERROR_PATTERNS in delivery-queue-recovery.ts:

• Grammy-style 4xx errors: /failed!\s*\(4\d{2}:/i — catches Call to sendMessage failed! (400: ...)
• Generic 400 Bad Request: /\b4\d{2}\b.*\bbad request\b/i
• Message too long: /message.*(is\s+)?too\s+long/i — channel-agnostic
• Entity too large: /request entity too large|payload too large/i — 413-style errors

5xx and network errors continue to be retried with backoff as before.

Tests

• Added recovery integration tests for Telegram 400 (message too long), 413 (entity too large), and verified 5xx errors still retry
• Added unit tests for isPermanentDeliveryError() covering new patterns and confirming 5xx is not matched

All 45 tests pass.

Closes #61680

Changed files

• src/infra/outbound/delivery-queue-recovery.ts (modified, +5/-0)
• src/infra/outbound/delivery-queue.policy.test.ts (modified, +10/-0)
• src/infra/outbound/delivery-queue.recovery.test.ts (modified, +57/-0)