Summary

resolveSlackThreadStarter() and resolveSlackThreadHistory() in extensions/slack/src/monitor/media.ts catch all errors and return null / [] without any logging. When the Slack API call fails (permissions, rate limits, token expiry, network errors), thread context silently disappears — the agent receives no thread history and starts a blank session.

Steps to Reproduce

1. Configure a cron job that delivers to a Slack DM channel
2. Simulate a Slack API failure on conversations.replies() (e.g., revoke im:history scope temporarily, or trigger rate limiting)
3. Reply in a thread to the delivered message
4. Observe: no error logged, agent responds with zero thread context

Expected Behavior

Errors from conversations.replies() should be logged at warn level so operators can diagnose missing thread context. The current silent catch {} pattern makes debugging impossible.

Actual Behavior

Errors are silently swallowed:

// extensions/slack/src/monitor/media.ts:425-427 (thread starter)
} catch {
  return null;
}

// extensions/slack/src/monitor/media.ts:517-519 (thread history)
} catch {
  return [];
}

No log, no warning, no metric. The system proceeds as if thread history simply doesn't exist.

Affected Code

• resolveSlackThreadStarter() — extensions/slack/src/monitor/media.ts
• resolveSlackThreadHistory() — extensions/slack/src/monitor/media.ts

Suggested Fix

Add logWarn or logVerbose in the catch blocks with the error message, channel ID, and thread timestamp. This preserves the best-effort behavior (return null/empty) while making failures visible.

Environment

• OpenClaw version: 2026.4.4
• OS: macOS 26.3

Also tracked in RemoteClaw fork: remoteclaw#2104