tech-debt(apiclient): regenerate log-search client; remove hand-marshalled bypass
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 2
- Forks
- 1
- Avg merge
- 13h 32m
- Merged PRs (30d)
- 45
Description
Context
Follow-up debt surfaced while reviewing the (now-closed) PR #19 "fix(logs): use project log search selectors".
That change moved function/frontend runtime + build log reads onto POST /projects/{id}/logs/search with the server's new nested resource selector ({type, ids, deployments:{ids}}).
Problem
The generated apiclient is stale: the typed body SearchProjectLogsJSONRequestBody (= common.LogSearchRequest) still carries the old flat shape (resource_type / resource_ids / bucket_count …) with no nested resource object.
To work around this, PR #19 hand-marshals a local logSearchRequest struct (internal/api/logs.go) and calls SearchProjectLogsWithBodyWithResponse instead of the typed SearchProjectLogsWithResponse. The same pattern was applied to GetProjectLogActivity (its apiclient test was rewritten to ...WithBody + a raw JSON literal).
This works today, but leaves a trap: any future caller using the typed SearchProjectLogsWithResponse will silently send the wrong wire format.
Proposed fix
- Regenerate
internal/apiclientfrom the updated OpenAPI spec soLogSearchRequest/ log-activity bodies match the nestedresourceshape. - Drop the hand-marshalled
logSearchRequesttypes ininternal/api/logs.goand switch back to the typedSearchProjectLogs*WithResponsecalls. - If the spec update is blocked, add a comment in
internal/api/logs.goexplaining why the typed body is intentionally bypassed, so it isn't "fixed" back to the broken typed call.
Smaller related cleanup
- Tests in
internal/api/client_test.goandinternal/api/frontends_test.goroute runtime-vs-build/logs/searchresponses by call order (len(logSearchBodies)==1) rather than by request content. Branch on the body (e.g.resource.deployments != nil→ build) to make them robust, matching the approach already used in the command-level tests.
Refs: PR #19, HOSTING-452.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the generated types and methods under internal/apiclient, then compare them with the nested resource shape described in the issue. Review internal/api/logs.go and switch its log-search calls back to the typed methods after regeneration. Run the relevant client, API, and frontend tests; done means typed requests use the nested resource shape and response routing checks request content rather than call order.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- api, cli, testing
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100