Fix API error log processing

[dobrac]

Ensure error logs are always included in build failure responses, even with pagination offsets or log limits.

Previously, error logs for a failed step might be omitted from the reason.logEntries field if the client's polling offset had moved past them or if the log limit truncated them. This PR introduces a fallback: if error logs for a failed step are not found within the currently paginated log batch, a fresh query is made from offset 0 specifically for that step to guarantee their inclusion in the API response.

---

Slack Thread

 

[cursor]

Cursor Agent can help with this pull request. Just @cursor in comments and I'll start working on changes in this branch.
_{Learn more about Cursor Agents}

[claude]

Performance Issue: Unbounded log fetch on every error response

On line 136, when error logs are not found in the current paginated batch, cli.GetLogs(ctx, templateID, buildID, 0, nil) is called with no level filter and offset 0. This fetches ALL logs from Loki (up to the templateBuildLogsLimit of 1,000 entries) for every error build status request where the client has paginated past the error logs.

Problem: This doubles the log fetching cost for the common polling pattern:

1. Client polls with increasing offset
2. Offset eventually exceeds error log position
3. Every subsequent poll triggers two full log fetches: the paginated one (line 116) AND the fallback from offset 0

Impact:

• Increased Loki query load during active polling
• Higher latency for error responses
• Memory allocation for potentially 2,000 log entries per request

Suggested mitigation: Pass a warn-level filter to only fetch warn/error logs:

warnLevel := logs.WarnLevel
allLogs := cli.GetLogs(ctx, templateID, buildID, 0, &warnLevel)

This reduces the fetch to only warning/error logs needed for result.Reason.LogEntries.