Repository navigation
/api/server/logs: documented 'lines' and 'level' query params are never parsed #46
Description
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 futureThe 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.
Activity
jordlee commentedon Aug 13, 2026
Reproduced on macOS — not platform-specific
Environment: ILCE-7M5 · USB · SDK V2.02.00 · darwin-arm64 · server 3.0.0
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"atCameraWebServer.cpp:3262-3266behaves 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 —
— with nothing about success, failure, or the
0x8D03rejections that came back over HTTP. A workinglevelfilter is of limited use while there is nothing aboveinfoto filter to, so this is worth fixing alongside some actual warn/error logging on the transfer paths.docs: document the transferProgress payload, the 409 busy response, a…
fix(server): honour the documented lines and level params on /api/ser…
docs: document the transferProgress payload, the 409 busy response, a…
jordlee commentedon Aug 13, 2026
Fixed on
mainby #54 (commit9152cd8).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 fromrequest.path" — described something impossible. The query string is now retained onHttpRequestwith aqueryParam()accessor; routing still matches the bare path, re-verified across 11 endpoints with and without a query.Verified on hardware (macOS, ILCE-7M5):
?lines=5?level=warninfo)?lines=3&level=warn?lines=notanumber?level=bogusinfoThe response also now reports
returnedalongsidetotal, 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
infofor alevelfilter to select. #54 also addedwarn/errorlogging on the transfer failure paths, which is what makes the filter useful when diagnosing the conditions in #40.