#12984: fix(signal): fall back to JSON-RPC for health check on signal-cli 0.13+
channel: signal
size: S
Cluster:
Cross-Platform Fixes
## Summary
Fixes `openclaw doctor` reporting Signal as `failed (unknown) - fetch failed` when using signal-cli 0.13.x, which removed the REST `/api/v1/check` endpoint.
Closes #12933
## Changes
- **`client.ts`**: `signalCheck()` now tries REST `/api/v1/check` first, then falls back to a JSON-RPC `version` call at `/api/v1/rpc` if REST fails. Works with both old (<0.13) and new (0.13+) signal-cli versions.
## Testing
- Added 5 new tests in `client.test.ts` covering:
- REST success (no fallback needed)
- REST 404 → JSON-RPC fallback succeeds
- REST throws → JSON-RPC fallback succeeds
- Both REST and JSON-RPC fail → returns error
- Both throw → returns error
- All 42 existing signal tests pass
🤖 Generated with Claude (AI-assisted)
<!-- greptile_comment -->
<h2>Greptile Overview</h2>
<h3>Greptile Summary</h3>
This PR updates the Signal health check to be compatible with signal-cli 0.13+ by attempting the legacy REST endpoint (`/api/v1/check`) first and falling back to a JSON-RPC `version` request against `/api/v1/rpc` when the REST check fails.
The change lives in `src/signal/client.ts` (`signalCheck`) and is exercised by a new `src/signal/client.test.ts` suite. `signalCheck` is used by `probeSignal` and the Signal monitor check path, so its success/failure semantics directly affect `openclaw doctor` and runtime health reporting.
Main concern: the fallback currently triggers on *any* non-OK REST response, which can mask genuine errors from the REST endpoint on older signal-cli versions (e.g., 401/403/5xx) if JSON-RPC happens to respond. Tests cover the 404/throw scenarios but don’t guard against this behavior change for other statuses.
<h3>Confidence Score: 3/5</h3>
- This PR is close to safe to merge, but the new fallback logic can change health-check semantics in a way that masks real failures.
- The implementation achieves the intended compatibility, but `signalCheck` now treats any non-OK REST response as a reason to fall back and potentially report success if JSON-RPC works, which is a behavioral regression for older signal-cli setups and is not covered by tests.
- src/signal/client.ts; src/signal/client.test.ts
<!-- greptile_other_comments_section -->
<!-- /greptile_comment -->
Most Similar PRs
#19398: feat(signal): support native signal-cli JSON-RPC WebSocket
by jxstanford · 2026-02-17
77.6%
#10709: fix(signal): guard JSON.parse against malformed RPC responses
by Yida-Dev · 2026-02-06
75.7%
#17818: Fix Signal reaction notification missing sender (support legacy 'so...
by Clawborn · 2026-02-16
75.1%
#2204: fix: exclude Linux native builds when downloading signal-cli on mac...
by Duartemartins · 2026-01-26
73.4%
#8767: fix(signal): validate cliPath before spawning signal-cli daemon
by yubrew · 2026-02-04
73.2%
#11602: fix(config): skip stale legacy config files when openclaw.json exists
by akoscz · 2026-02-08
73.0%
#2744: FIX(imessage): preserve signal info in RPC close handler
by sal-jim · 2026-01-27
72.8%
#16704: Signal: reduce REST lock contention in send/receive loop
by hashpuppy · 2026-02-15
72.7%
#8271: feat(signal): Add full quoted message context support
by ProofOfReach · 2026-02-03
72.1%
#9173: Fix: Improve error messaging for API rate limits and billing errors
by vishaltandale00 · 2026-02-04
72.0%