connect() discards the synchronous SDK::Connect status — failures report a 15s timeout that never happened

[jordlee]

Symptom

A failed POST /api/cameras/{id}/connection returns:

Connection did not complete within 15s. If this is a network connection, check
that remote shooting is enabled on the camera.

…but it returns in ~3.6s, and no 15s wait ever occurred. The message names the wrong cause and a wait that did not happen, so it sends you toward camera network settings when the failure was elsewhere entirely.

Cause

CameraDeviceRest::connect() zeroes the error, then drops the SDK status on the synchronous-failure path:

https://github.com/crsdk/alpha-sdk-api/blob/main/api/server/src/device/CameraDeviceRest.cpp#L93-L110

m_lastError.store(0);
auto status = SDK::Connect(...);
if (CR_FAILED(status)) {
    return false;              // <-- status never stored into m_lastError
}

The controller then skips wait_for_connection() (it only runs if (connect_result)), so last_error() is still 0 and it falls into the "no SDK error ⇒ it must have timed out" branch:

https://github.com/crsdk/alpha-sdk-api/blob/main/api/server/src/CameraWebController.cpp#L714-L719

That branch's assumption is sound only when the wait actually ran. On a synchronous failure it is reached with no wait and no error, and it fabricates a timeout.

Impact

Every synchronous SDK::Connect failure is misreported as a 15s network timeout, and the SDK's real error code is discarded — so the one piece of information that would identify the actual fault never reaches the caller or the logs. Observed via the MCP bundle as Connect failed: Connection did not complete within 15s, returned instantly.

Suggested fix

Store the status before returning, so the existing error-code branch can report it:

if (CR_FAILED(status)) {
    m_lastError.store(status);
    return false;
}

Then make the timeout branch in CameraWebController conditional on the wait having actually run, so "timed out" can only be claimed when something was waited on.

Environment

macOS 15 (arm64), ILCE-7M5 over USB, main @ 4e1927a.

[jordlee]

Could not reproduce on macOS after three attempts — the defect is real, but the path may be unreachable in practice

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

The code defect is confirmed by reading, exactly as described — CameraDeviceRest.cpp:105-107 does if (CR_FAILED(status)) return false; with status never stored, and the controller's timeout branch is then reached with last_error() == 0.

But I could not get the runtime to take that branch:

Attempt	Result	Time	Path
Second process contending for the camera	real code 0x00008208 reported	4.1 s	async
Same, with SSH auth supplied	real code 0x00008208 reported	4.1 s	async
After SIGKILLing a server holding the camera	real code 0x00008219 reported	3.7 s	async

Every one returned the genuine SDK code, never the fabricated "Connection did not complete within 15s". All three went through wait_for_connection(), where m_lastError is stored correctly — that is, the path that works.

So on macOS with SDK V2.02, SDK::Connect appears to return success synchronously and report failure asynchronously, in every failure mode I could produce. The synchronous-failure branch is real code, but I have no evidence it is reachable here.

That does not invalidate the report — it was observed on macOS 15 at 4e1927a, and the described symptom (instant return, message naming a 15 s wait that never happened) is specific enough that it clearly happened. Two possibilities worth distinguishing before spending time on it:

1. It needs a condition I did not find. The remaining candidate I could not test is a stale device handle — discover the camera, physically unplug it, then connect without re-discovering. That plausibly fails inside SDK::Connect before any async work begins. It needs someone at the hardware to unplug at the right moment.
2. It was fixed or changed by an SDK update between the report and V2.02.00.

Suggestion: the one-line fix (m_lastError.store(status) before the return false) is worth taking regardless — it is strictly more correct and costs nothing. But the priority should probably drop, since every connect failure I can actually produce reports its code correctly. The higher-impact half of this pair is #39, where the codes that do surface are mislabelled — and which I reproduced 3/3 from ordinary process contention.