In the default 'on-start' receive mode, signal-cli's daemon
auto-pulls inbound messages and pushes them to its JSON-RPC clients
the moment they arrive from the Signal servers. If no websocket
subscriber is currently attached to /v1/receive/{number} — for
example during a brief subscriber redeploy — the receiver loop in
signal-cli-rest-api drops the message via a non-blocking channel
send (see the 'no receiver' debug log in ReceiveData). signal-cli
has already acknowledged the message to Signal, so it is never
redelivered.
Add support for signal-cli's --receive-mode=manual, opt-in via the
new JSON_RPC_RECEIVE_MODE=manual environment variable. In manual
mode signal-cli does NOT auto-receive; signal-cli-rest-api now
issues subscribeReceive when a websocket subscriber attaches and
unsubscribeReceive when the last subscriber detaches. While no
subscriber is attached, signal-cli does not pull messages from the
Signal servers, so they remain buffered server-side under Signal's
normal retention rules and are delivered to the next subscriber
that attaches.
Implementation:
* jsonrpc2-helper.go: thread JSON_RPC_RECEIVE_MODE through to the
daemon launch command line.
* jsonrpc2.go: add per-account subscription tracking with
refcounting; subscribeReceive/unsubscribeReceive helpers; an
unwrap step in ReceiveData so manual-mode notifications
({subscription,result}) and auto-mode notifications (envelope
directly) reach downstream consumers in the same shape.
* client.go, api.go: thread the account number through
GetReceiveChannel so the JsonRpc2Client can attach the right
subscription.
The change is fully backward compatible: when JSON_RPC_RECEIVE_MODE
is unset or set to 'on-start', signal-cli runs in auto mode and the
new subscribeReceive code path is bypassed (account is empty, no
RPC issued).
Closes#255 (the same root cause: no subscriber → 'no receiver'
drop).
24 functions in client.go use 'jsonRpc2Client, err :=' inside if blocks
where 'var err error' is already declared at function scope. The := creates
a new block-scoped err that shadows the outer one, causing 15 functions to
silently return nil instead of the actual error in JSON-RPC mode.
Fixes#506
Expose the new signal-cli v0.14.0 --ignore-avatars and --ignore-stickers
flags across all modes:
* JSON-RPC mode: JSON_RPC_IGNORE_AVATARS and JSON_RPC_IGNORE_STICKERS
environment variables
* Normal/Native mode: ignore_avatars and ignore_stickers query parameters
on the /v1/receive endpoint
* Auto-receive scheduler: AUTO_RECEIVE_SCHEDULE_IGNORE_AVATARS and
AUTO_RECEIVE_SCHEDULE_IGNORE_STICKERS environment variables
Follows the existing pattern of --ignore-attachments and --ignore-stories.
Refs #776, #723
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* when the connection the signal-cli daemon is lost in json-rpc mode,
the open connection will be closed and a new connection attempt will
be made. If after 15 connection attempts we are unable to connect to
the signal-cli daemon, we give up and abort.
