Add line length truncate buffer

[mattdholloway]

Summary

This pull request improves the handling of very large log lines in the ProcessResponseAsRingBufferToEnd function in pkg/buffer/buffer.go and adds comprehensive tests in a new test file. The changes ensure that extremely long lines (such as those found in GitHub Actions logs) are truncated to a maximum size, with a clear marker indicating truncation, and that the ring buffer logic is robustly tested.

Why

Fixes #

What changed

MCP impact

• No tool or API changes
• Tool schema or behavior changed
• New tool added

Prompts tested (tool changes only)

Security / limits

• No security or limits impact
• Auth / permissions considered
• Data exposure, filtering, or token/size limits considered

Tool renaming

• I am renaming tools as part of this PR (e.g. a part of a consolidation effort)
  • I have added the new tool aliases in deprecated_tool_aliases.go
• I am not renaming tools as part of this PR

Note: if you're renaming tools, you must add the tool aliases. For more information on how to do so, please refer to the official docs.

Lint & tests

• Linted locally with ./script/lint
• Tested locally with ./script/test

Docs

• Not needed
• Updated (README / docs / examples)

[Copilot]

Pull request overview

This PR adds handling for extremely long lines (exceeding 10MB) in the buffer package's ring buffer processing. The change aims to prevent failures when GitHub Actions logs contain very long lines (e.g., base64 content, minified JavaScript).

Changes:

• Increased scanner's max token size from 1MB to 10MB
• Added fallback byte-by-byte line reading when scanner encounters bufio.ErrTooLong
• Added truncation logic that keeps first 1000 bytes of lines exceeding 10MB

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 8 comments.

File	Description
pkg/buffer/buffer.go	Adds maxLineSize constant, updates scanner buffer size, implements processWithLongLineHandling fallback function for truncating extremely long lines
pkg/buffer/buffer_test.go	Adds unit tests for normal lines, ring buffer behavior, long line handling (11MB), and lines at max size (1MB)

Comments suppressed due to low confidence (2)

pkg/buffer/buffer.go:96

• When the long line is encountered as the first line in the body, lines[writeIndex] at index 0 will be overwritten with the truncation marker. If the long line is encountered at writeIndex position N, the truncation marker overwrites whatever was at position N. This causes data to be incorrectly overwritten in the ring buffer before continuing to read remaining lines. The marker should either be added as a separate entry in the ring buffer rotation, or the already-read lines should be properly preserved when transitioning to the fallback handler.

	truncatedMarker := "[LINE TRUNCATED - exceeded maximum line length of 10MB]"
	lines[writeIndex] = truncatedMarker
	validLines[writeIndex] = true
	totalLines++
	writeIndex = (writeIndex + 1) % maxJobLogLines

pkg/buffer/buffer.go:101

• The maxDisplayLength constant is hardcoded to 1000 bytes but there's no clear rationale documented for this specific value. Consider documenting why 1000 bytes was chosen (e.g., "sufficient to show error context while keeping output manageable") or making it configurable. This magic number affects user experience when dealing with truncated lines.

	const maxDisplayLength = 1000 // Keep first 1000 chars of truncated lines

[Copilot]

When the fallback function is called, it has already lost the httpResp reference but returns nil for the *http.Response parameter. The caller expects to receive the httpResp back (as seen in the function signature and normal return path), but the fallback path returns nil. This inconsistency could cause nil pointer dereferences in calling code that expects a non-nil response. Either return httpResp consistently or document why nil is acceptable in this error recovery path.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.