DELETE /connection reports "Disconnect timed out" with connected:true, then POST /connection hangs forever

[takusaito-ctrl]

Environment: ILCE-7M5 · USB · Camera Remote SDK V2.02.00 · linux-arm64 (Raspberry Pi, kernel 6.8.0-1051-raspi) · server 3.0.0

Summary

After a stuck RemoteTransfer download (#40), the connection lifecycle breaks in a way that is unrecoverable in-process. DELETE /connection reports failure while actually having disconnected the camera, and the subsequent POST /connection never returns.

Reproduction

1. Connect in remote-transfer.
2. Trigger the stuck download from RemoteTransfer full-size download silently never completes and latches the whole subsystem into 0x8D03 #40.
3. DELETE /api/cameras/{id}/connection:

HTTP 400 {"message":"Disconnect timed out", "camera":{"connected":true, ...}}

The status is wrong twice over — the camera is disconnected at this point, yet the response reports connected:true and a 400.

4. POST /api/cameras/{id}/connection — hangs forever. Last log line is:

[SSE] Wired event callback for camera: CFCA6014E092

5. Every camera-touching endpoint now blocks indefinitely. GET /api/server/logs still answers 200 because it takes no camera lock — which is a useful signal that the process is alive but the camera lock is held. SIGTERM does not kill it.

Isolation

DELETE /connection is clean in both remote and remote-transfer when no download was attempted. The stuck download is the trigger, not the connection mode. Verified on a fresh process twice.

Expected

• The reported connected state must reflect reality; a disconnect that actually disconnected should not report 400 + connected:true.
• A failed disconnect must leave the controller in a state where a subsequent connect can either succeed or fail fast — never block forever.
• Consider a bounded timeout on the connect path so a held camera lock surfaces as 503/409 instead of an infinite hang.

Related

Root cause is #40. The shutdown-side consequence is #41.

[jordlee]

Isolation corroborated on macOS — the stuck transfer really is the trigger

Environment: ILCE-7M5 (CFCA6014E092) · USB · SDK V2.02.00 · darwin-arm64 · server 3.0.0

On a healthy remote-transfer session — four successful downloads, no stuck transfer — the connection lifecycle is completely clean:

DELETE /api/cameras/CFCA6014E092/connection
  200 {"success":true,"message":"Camera disconnected successfully"}   in 0.14s

POST /api/cameras/CFCA6014E092/connection {"mode":"remote-transfer"}
  200 {"success":true,"message":"Camera connected successfully in remote-transfer mode"}   in 3.86s

No "Disconnect timed out", no connected:true on a disconnected camera, no hang on the subsequent connect.

This supports the isolation already in the report — the failure needs the stuck download, not merely remote-transfer mode. Since that stuck download does not reproduce on macOS at all (see #40), this issue is Linux-only in practice.

One small corroboration of #47 in passing: the successful DELETE still returned a partially-empty camera block, {"connected":false,"model":"","id":"CFCA6014E092"} — model empty, though id was populated here rather than the fully-empty block reported there.