event consume blocked by remote online_instance_cnt=1 but status/stop cannot recover #1381

Summary

lark-cli event consume can be blocked by a remote active WebSocket connection reported by /open-apis/event/v1/connection, but the CLI only provides local event status / event stop and offers no way to identify or disconnect the remote/stale connection.

This leaves users stuck when online_instance_cnt > 0 is reported by the API but no local bus is running on the current machine.

Reproduction / observed behavior

Run an event consumer for an app/profile where the Feishu/Lark API reports an existing active event connection, but the current machine has no local event bus:

lark-cli --profile <profile> event consume im.chat.member.bot.added_v1 --as bot --timeout 3s < <(tail -f /dev/null)

Observed stderr:

[event] consuming as <profile> (<app_id>)
[event] local bus not found; checking remote connections...
[event] remote connection check: online_instance_cnt=1
Error: another event bus is already connected to this app (1 active connection(s) detected via API); only one bus should run globally to avoid duplicate event delivery

Then local status/stop does not help:

lark-cli --profile <profile> event status --json

reports the local bus as not running.

lark-cli --profile <profile> event stop --force --json

cannot stop the remote connection because event stop only targets local bus instances discovered through local IPC/process state.

A direct API probe shows the blocker is remote/server-side:

lark-cli --profile <profile> api GET /open-apis/event/v1/connection --as bot

returns:

{"code":0,"data":{"online_instance_cnt":1},"msg":""}

Trying to delete the same resource does not work:

lark-cli --profile <profile> api DELETE /open-apis/event/v1/connection --as bot

returns a 404/page-not-found response.

Why this is hard to recover from

The current event consume preflight is correct in spirit: multiple upstream WebSocket connections for the same app can split event delivery, so starting another connection is unsafe.

However, when the existing connection is from another host, an orphaned process, or a stale server-side connection, the user has no CLI-visible owner information and no CLI recovery operation.

This is especially painful for agent / automation workflows where an earlier process may have been launched from a transient shell and then disappeared locally while the platform still reports one active connection.

Source-level notes

From current source:

• internal/event/consume/remote_preflight.go calls GET /open-apis/event/v1/connection and only reads online_instance_cnt.
• internal/event/consume/startup.go refuses to start if that count is greater than zero.
• cmd/event/status.go and cmd/event/stop.go only inspect/stop local event bus instances.
• The hidden legacy command event +subscribe --force can bypass a local single-instance lock, but its own help warns that this is unsafe because the server may randomly split events across connections. That is not a reliable recovery path for one-shot events.

Expected behavior

At least one of these would make the situation recoverable:

1. lark-cli event status shows remote connection count and, if the API supports it, owner metadata such as instance ID, hostname, client ID, connected time, or IP.
2. lark-cli event stop documents clearly that it is local-only and suggests the remote connection recovery path when online_instance_cnt > 0 blocks startup.
3. A supported command/API wrapper exists to disconnect stale remote event connections for the current app, if the platform supports it.
4. event consume error message distinguishes local bus conflicts from remote-only conflicts and gives actionable remediation steps.
5. If remote disconnect is not possible by design, document that users must stop the owner host/process, wait for platform timeout, or use a separate app/profile.

Environment

• Command area: lark-cli event consume
• Event key: reproduced with im.chat.member.bot.added_v1
• Auth identity: bot
• Affected behavior: remote active connection preflight and local-only status/stop recovery