Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix fix(line): upgrade hardcoded error fallback to typed error routing [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#60813•Fetched 2026-04-08 02:46:53
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Author
garnetlyxgarnetlyx
Participants
garnetlyxgarnetlyx
Timeline (top)
cross-referenced ×1referenced ×1

Error Message

LINE is the only non-Telegram channel that sends a user-visible fallback message on dispatch failure, but it uses a hardcoded generic string via a bare try/catch rather than the typed error routing introduced for Telegram. "Sorry, I encountered an error processing your message."

Fix Action

Fix / Workaround

LINE is the only non-Telegram channel that sends a user-visible fallback message on dispatch failure, but it uses a hardcoded generic string via a bare try/catch rather than the typed error routing introduced for Telegram.

PR fix notes

PR #60830: fix(agents): detect empty provider responses as failures, improve Telegram error routing

Description (problem / solution / changelog)

Summary

  • Adds EmptyResponseError typed class in model-fallback.ts; replaces the fragile string-matched new Error("Empty response content received from provider")
  • In runFallbackAttempt: treats a raw provider response with content: [] and no meta field as a failure, triggering fallback to the next candidate (benefits all channels)
  • In Telegram dispatch: tracks lastError via onError and an outer try/catch; routes the user-visible fallback message by error type (rate limit / empty response / general); re-throws aborts and timeouts so they don't produce spurious fallback replies; re-throws other dispatcher crashes after cleanup so callers still see the failure for logging/alerting
  • Adds tests for the empty-content detection (triggers fallback) and the meta field guard (accepted as valid)

Related

Follow-up work tracked in:

  • #60812 — extend user-visible error fallback to Discord, Slack, Signal, WhatsApp
  • #60813 — upgrade LINE's hardcoded error fallback to typed error routing

Test plan

  • pnpm test src/agents/model-fallback.test.ts — all tests pass including 3 new ones
  • bunx oxlint src/agents/model-fallback.ts src/telegram/bot-message-dispatch.ts — 0 errors
  • Telegram: provider returns empty content → user sees "I wasn't able to generate a response. Please try rephrasing your question."
  • Telegram: rate-limited provider → user sees rate limit message
  • Telegram: /stop or timeout → no spurious fallback reply sent

Changed files

  • .gitignore (modified, +2/-0)
  • src/agents/model-fallback.test.ts (modified, +63/-1)
  • src/agents/model-fallback.ts (modified, +47/-3)
  • src/telegram/bot-message-dispatch.ts (modified, +195/-151)

Code Example

"Sorry, I encountered an error processing your message."
RAW_BUFFERClick to expand / collapse

Problem

LINE is the only non-Telegram channel that sends a user-visible fallback message on dispatch failure, but it uses a hardcoded generic string via a bare try/catch rather than the typed error routing introduced for Telegram.

Current LINE fallback (src/line/monitor.ts):

"Sorry, I encountered an error processing your message."

This does not distinguish between rate limits, empty provider responses, or general errors.

Proposed fix

Replace the hardcoded fallback with the same resolveFailoverReasonFromError + EmptyResponseError routing used by Telegram, once the shared helper from #60812 is available.

Related

  • Broader channel fallback tracking: #60812
  • EmptyResponseError introduced in the model-fallback empty-response fix PR

extent analysis

TL;DR

Replace the hardcoded LINE fallback message with a dynamic error routing mechanism using resolveFailoverReasonFromError to provide more informative error messages.

Guidance

  • Identify the shared helper function from #60812 and ensure it is available for use in the LINE channel code.
  • Replace the hardcoded string in src/line/monitor.ts with a call to resolveFailoverReasonFromError to handle different types of errors, such as rate limits and empty provider responses.
  • Consider adding a check for EmptyResponseError to provide a specific error message for this case.
  • Review the broader channel fallback tracking issue #60812 to ensure consistency across channels.

Example

// Example replacement for the hardcoded fallback message
const fallbackMessage = resolveFailoverReasonFromError(error);
if (error instanceof EmptyResponseError) {
  // Handle empty response error specifically
} else {
  // Handle other types of errors
}

Notes

The proposed fix relies on the availability of the shared helper function from #60812. If this function is not yet available, the fix cannot be implemented.

Recommendation

Apply workaround by replacing the hardcoded fallback message with a dynamic error routing mechanism using resolveFailoverReasonFromError, once the shared helper function is available, to provide more informative error messages and consistency with the Telegram channel.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#integration issue#index setup#retrieval issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING