Summary

LINE webhook provider's startAccount() resolves immediately (~150ms) instead of staying pending, causing the channel supervisor to auto-restart it in a loop until the 10-attempt limit is reached.

Steps to reproduce

1. Configure LINE channel with webhook mode (token via env vars)
2. Start or restart the gateway (openclaw gateway restart)
3. Check openclaw channels status --json — LINE shows running: false within ~150ms
4. Check logs — [line] [default] auto-restart attempt 1/10 in 5s repeats until giving up

Expected behavior

The LINE provider should stay running after startup (startAccount() should remain pending until abortSignal fires), keeping the channel status as running: true.

Actual behavior

LINE provider starts, registers the webhook HTTP route, then returns immediately (~150ms). The channel supervisor interprets this as "channel exited" and triggers auto-restart loop. lastError: null — no error is thrown.

Note: Despite running: false, the webhook route IS registered and LINE messages are received/responded to. The bug is in the provider lifecycle, not in actual functionality.

OpenClaw version

2026.2.24 (also reproduced on 2026.2.23)

Operating system

macOS (M1 Mac)

Install method

npm global

Logs, screenshots, and evidence

openclaw channels status --json (LINE section):
  configured: true, running: false
  lastStartAt: 1771991113274, lastStopAt: 1771991113425 (~151ms)
  lastError: null
  tokenSource: "env", mode: "webhook"

Log lines:
  [line] [default] starting LINE provider (ガリィ)
  [line] [default] auto-restart attempt 1/10 in 5s
  [line] [default] giving up after 10 restart attempts
  [health-monitor] [line:default] hit 3 restarts/hour limit, skipping

Impact and severity

Affected: LINE channel users on webhook mode
Severity: Low (LINE actually works despite status showing false)
Frequency: 100% repro
Consequence: Unnecessary restart loop, potential 429 rate limiting from LINE API, misleading channel status

Additional information

Diagnosed with help from Krill in Discord #help. The root cause appears to be that monitorLineProvider() registers the HTTP webhook route and then returns immediately without awaiting abortSignal. The minimal fix would be to keep the provider promise pending until abortSignal fires.

Discord thread: https://discord.com/channels/1456350064065904867/[thread-id]