fix: extract logs field from application logs API response - #48
Conversation
Coolify's GET /applications/{uuid}/logs returns {"logs": "..."},
not a bare string. getApplicationLogs treated the whole response as
the log text, so downstream truncateLogs() called .split() on an
object and threw "logs.split is not a function" on every call.
Fixes #120
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 51 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Pull request overview
Fixes CoolifyClient.getApplicationLogs() to match Coolify’s real API response shape for GET /applications/{uuid}/logs, preventing runtime failures in the application_logs MCP tool path.
Changes:
- Updated
getApplicationLogs()to readresponse.logsfrom the API response wrapper. - Updated unit test mocks that previously assumed a bare-string logs response.
- Documented the
/applications/{uuid}/logsresponse wrapper inCLAUDE.mdunder known Coolify API gotchas.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| src/lib/coolify-client.ts | Adjusts getApplicationLogs() to extract the logs field from the API response. |
| src/tests/coolify-client.test.ts | Updates fetch mocks to return { logs: ... } to reflect the real endpoint shape. |
| CLAUDE.md | Documents the logs endpoint wrapper response as a known Coolify API quirk. |
Address PR #48 review feedback: getApplicationLogs assumed logs is always a string without checking, silently letting an unrecognized shape propagate a non-string past this boundary. Mirrors the normalizeDeploymentsResponse pattern (issue #24): accept the known {logs: string} shape or a bare string, throw a clear error otherwise.
Summary
getApplicationLogstreated Coolify'sGET /applications/{uuid}/logsresponse as a bare string, but the real API returns{"logs": "..."}— sotruncateLogs()called.split()on an object and threwlogs.split is not a functionon everyapplication_logsMCP call..logsfrom the response; updated existing test mocks that (incorrectly) assumed a bare-string response to match the real API shape; documented the gotcha inCLAUDE.mdalongside the other known Coolify API quirks.Test plan
bun run test— 563/563 passbun run lint/bun run buildcleanentire-dev-app) — confirmedgetApplicationLogsnow returns a proper string instead of throwingFixes jurislm/jurislm-tools#120