/api/server/logs: documented 'lines' and 'level' query params are never parsed

[takusaito-ctrl]

Environment: ILCE-7M5 · USB · Camera Remote SDK V2.02.00 · linux-arm64 · server 3.0.0

Summary

GET /api/server/logs documents lines and level query parameters in api/openapi.yaml, but the handler ignores them entirely and always returns 100 entries at info.

The code

api/server/src/CameraWebServer.cpp:3262-3266, in handleApiServerLogs:

// Parse query parameters: ?lines=100&level=info
int maxLines = 100;
std::string minLevel = "info";
// Query params could be parsed from request.path if needed in the future

The values are hardcoded and the comment acknowledges the parsing was never implemented.

Observed

?lines=5 and ?level=error both return the same unfiltered 100-entry payload as a bare request.

Expected

Either implement the parsing, or remove the parameters from the OpenAPI spec so the contract matches reality. Given the spec is the stated source of truth for this project, implementing them is probably the right call — a level filter in particular is genuinely useful when diagnosing the camera-lock hangs in #41/#43, since /api/server/logs is the one endpoint that still responds while the camera lock is held.

[jordlee]

Reproduced on macOS — not platform-specific

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

GET /api/server/logs?lines=5&level=error

• lines=5 → 26 entries returned.
• level=error → every entry "level":"info".

Both parameters ignored, matching the report exactly and confirming the hardcoded maxLines = 100 / minLevel = "info" at CameraWebServer.cpp:3262-3266 behaves identically on darwin.

Worth adding to the argument for implementing rather than removing these: during the #40 transfer sweep, the log was the only place to look for a transfer outcome, and it records only the request line —

info  POST /api/cameras/CFCA6014E092/sd-card/slot/1/files/131198/1/download

— with nothing about success, failure, or the 0x8D03 rejections that came back over HTTP. A working level filter is of limited use while there is nothing above info to filter to, so this is worth fixing alongside some actual warn/error logging on the transfer paths.

[jordlee]

Fixed on main by #54 (commit 9152cd8).

Both parameters are now parsed. The root cause was one layer deeper than this issue describes: parseRequest() stripped the query string off the path and discarded it, so the handler's comment — "could be parsed from request.path" — described something impossible. The query string is now retained on HttpRequest with a queryParam() accessor; routing still matches the bare path, re-verified across 11 endpoints with and without a query.

Verified on hardware (macOS, ILCE-7M5):

Request	Result
?lines=5	5 entries (was 26)
?level=warn	warn entries only (was all info)
?lines=3&level=warn	both applied
?lines=notanumber	falls back to the default
?level=bogus	falls back to info

The response also now reports returned alongside total, so a filtered response is not mistaken for data loss.

Related, and the reason this mattered beyond tidiness: the transfer paths previously logged nothing but the request line, so there was nothing above info for a level filter to select. #54 also added warn/error logging on the transfer failure paths, which is what makes the filter useful when diagnosing the conditions in #40.