Transfer poll loop drops timed-out transfers silently — no error event ever reaches the client

[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

transferPollLoop() in api/server/src/device/CameraDeviceRest.cpp does have a 120-second timeout for pending transfers, but when it fires it simply erases the entry and emits nothing. A client that started a download via 202 is left waiting forever with no completion, no failure, and no log line.

The code

// CameraDeviceRest.cpp:1520-1522
for (auto it = m_pendingTransfers.begin(); it != m_pendingTransfers.end();) {
    auto elapsed = std::chrono::duration_cast<std::chrono::seconds>(now - it->startTime).count();
    if (elapsed > 120) { it = m_pendingTransfers.erase(it); continue; }

Compare with the success path, which does emit (line 1551-1556):

if (m_eventCallback) {
    std::ostringstream oss;
    oss << "{\"percent\":100,\"notify\":\"0x20093\",\"filename\":\""
        << jsonEscape(path.string()) << "\",\"synthetic\":true}";
    m_eventCallback("transferProgress", oss.str());

The timeout branch has no equivalent.

Why it bites

For a transfer that never starts moving (see #40) the silence is total:

• The SDK's own OnNotifyRemoteTransferResult(..., CrChar* filename) (line 1461) never fires, so no real transferProgress.
• The polling fallback correctly refuses to declare success, because completion requires size == lastSize && size > 0 (line 1542) and the file is stuck at 0 bytes.
• At 120s the entry is erased with no notification.

Net effect: POST .../download returns 202 and the client can never learn the outcome by any means.

Expected

Emit a terminal event on the timeout branch — e.g. transferProgress with a failure notify code, or a dedicated transferFailed event carrying the content/file id and the reason. Log it too; right now nothing is written to the server log either.

Related minor gaps in the same area

Two callbacks next to it are unimplemented stubs (lines 1483-1488):

void CameraDeviceRest::OnNotifyRemoteTransferResult(CrInt32u, CrInt32u, CrInt8u* /*data*/, CrInt64u /*size*/) {}
void CameraDeviceRest::OnNotifyRemoteTransferContentsListChanged(CrInt32u, CrInt32u, CrInt32u) {}

The first only matters if the buffer-based GetRemoteTransferContentsData() is ever adopted, so it is currently harmless. The second means clients get no notification when new content appears on the card during a remote-transfer session, which is a real (if lower-priority) functional gap.

Related

#40 (the stuck transfer that exposes this).

[jordlee]

Labelled linux/mac/windows rather than linux alone, deliberately — the distinction matters for how this gets prioritised.

The defect is platform-independent: the timeout branch at CameraDeviceRest.cpp:1520-1522 erases the pending transfer and emits nothing on every platform. Nothing about it is Linux-specific.

What is currently Linux-only is the trigger. Reaching that branch requires a transfer that never completes, and on macOS transfers complete reliably — see #40 (comment), where #40's exact failing file transfers in under five seconds. So the branch is latent here rather than absent.

Practical consequence: this is a real cross-platform gap that happens to be unobservable outside Linux today. If #40's root cause is fixed, this branch becomes near-unreachable everywhere — but it should still emit, because "a transfer stalled for 120 s" is a condition any platform can hit given a bad cable or a card error, and silence is the wrong response to it on all of them.

I could not exercise the branch on macOS to verify the fix behaviour; whoever implements it should test on the Pi where the condition is reproducible.