github/github-mcp-server · error

failed to process log content: %w

Error message

failed to process log content: %w

What it means

Returned by downloadLogContent (pkg/github/actions.go:186) when buffer.ProcessResponseAsRingBufferToEnd fails while streaming the downloaded log body into the fixed-size ring buffer. The only error that helper can produce is the wrapped body-read error from pkg/buffer/buffer.go:113, so this error is that read failure (connection reset mid-body, proxy timeout, TLS drop) with one extra layer of wrapping.

Source

Thrown at pkg/github/actions.go:186

func downloadLogContent(ctx context.Context, logURL string, tailLines int, maxLines int) (string, int, *http.Response, error) {
	prof := profiler.New(nil, profiler.IsProfilingEnabled())
	finish := prof.Start(ctx, "log_buffer_processing")

	httpResp, err := http.Get(logURL) //nolint:gosec
	if err != nil {
		return "", 0, httpResp, fmt.Errorf("failed to download logs: %w", err)
	}
	defer func() { _ = httpResp.Body.Close() }()

	if httpResp.StatusCode != http.StatusOK {
		return "", 0, httpResp, fmt.Errorf("failed to download logs: HTTP %d", httpResp.StatusCode)
	}

	bufferSize := min(tailLines, maxLines)

	processedInput, totalLines, httpResp, err := buffer.ProcessResponseAsRingBufferToEnd(httpResp, bufferSize)
	if err != nil {
		return "", 0, httpResp, fmt.Errorf("failed to process log content: %w", err)
	}

	lines := strings.Split(processedInput, "\n")
	if len(lines) > tailLines {
		lines = lines[len(lines)-tailLines:]
	}
	finalResult := strings.Join(lines, "\n")

	_ = finish(len(lines), int64(len(finalResult)))

	return finalResult, totalLines, httpResp, nil
}

// ActionsList returns the tool and handler for listing GitHub Actions resources.
func ActionsList(t translations.TranslationHelperFunc) inventory.ServerTool {
	tool := NewTool(
		ToolsetMetadataActions,
		mcp.Tool{

View on GitHub (pinned to 0ea1f775a7)

Solutions

  1. Retry the tool call - a fresh signed URL and fresh connection usually completes
  2. Shrink the exposure window by lowering tail_lines and content window size
  3. If reproducible for one specific job, that log may be abnormally large - fetch it out-of-band (gh run download) instead
  4. Unwrap to confirm the transport cause before assuming a server bug

Example fix

// before
processed, total, httpResp, err := buffer.ProcessResponseAsRingBufferToEnd(httpResp, bufferSize)
if err != nil {
    return "", 0, httpResp, fmt.Errorf("failed to process log content: %w", err)
}

// after - one bounded retry on transient body failure, fresh URL each time
var out string
var totalLines int
for attempt := range 2 {
    u, _, e := client.Actions.GetWorkflowJobLogs(ctx, owner, repo, jobID, 1)
    if e != nil {
        return "", 0, nil, e
    }
    out, totalLines, httpResp, err = tryDownloadAndBuffer(ctx, u.String(), bufferSize)
    if err == nil || attempt == 1 {
        break
    }
}
Defensive patterns

Strategy: retry

Validate before calling

// Before streaming: context live + body present
if ctx.Err() != nil {
    return ctx.Err()
}
if httpResp == nil || httpResp.Body == nil {
    return errors.New("nothing to buffer")
}

Try / catch

if err != nil {
    if errors.Is(err, context.Canceled) {
        return err
    }
    // body read broke mid-stream: fresh URL, one retry
    return fetchAndBufferWithRetry(ctx, client, owner, repo, jobID, tailLines, 1)
}

Prevention

When it happens

Trigger: Downloading large job logs with return_content=true when the response body read aborts mid-stream after the 200 status was already received: connection reset by peer, idle-timeout on proxies for slow transfers, or abrupt socket close by blob storage.

Common situations: Multi-hundred-MB debug logs streaming through corporate proxies; mobile/high-latency links dropping long transfers; server processes killed mid-read.

Related errors


AI-assisted analysis of github/github-mcp-server@0ea1f775a7 (2026-08-15). Data as JSON: /api/errors/32474c11c59f62be. Report an issue: GitHub.