Signal log truncation and retry with larger tail on step miss

[sahilnyk]

Fixes #4425

Describe the changes you have made in this PR -

integrations/github/tools/actions.py only, per the issue's scope:

1. Truncation signal: get_github_actions_step_log now returns truncated, returned_length, and original_length so the agent can tell when the 500-line tail cut off part of the job log.

2. Retry on step miss: when a requested step_name/step_number falls back to match_strategy="full-log" and the log was truncated, it re-fetches once with a bigger tail_lines, sized from the log's own reported original_length (capped at 20000), instead of settling for a partial log.

3. Fixed the ungrouped-only log bug: a log with zero ##[group] markers was fabricating a fake single "full-log" section that got miscounted as step 1, so step_number=1 wrongly reported match_strategy="step_number". Root-cause fix: _extract_log_sections now returns [] for that case and lets extract_step_log's real full-log fallback handle it.

Demo/Screenshot for feature changes and bug fixes -

ruff check, ruff format --check, and mypy all pass.

tests/tools/test_github_actions_tool.py: 38/38 passed (35 existing + 3 new regression tests, one per fix above).

Broader tests/tools -k github: 218 passed.

Code Understanding and AI Usage

Did you use AI assistance (ChatGPT, Claude, Copilot, etc.) to write any part of this code?

• No, I wrote all the code myself
• Yes, I used AI assistance (continue below)

If you used AI assistance:

• I have reviewed every single line of the AI-generated code
• I can explain the purpose and logic of each function/component I added
• I have tested edge cases and understand how the code handles them
• I have modified the AI output to follow this project's coding standards and conventions

Explain your implementation approach:

Read the linked issue 2719 thread first: a contributor there flagged that get_job_logs's response exposes the total log length for a follow-up fetch, and a maintainer comment confirmed the step_number bounds bug was fixed in PR 2755, but only for logs with real group blocks, not the zero-groups case this issue calls out. Traced extract_step_log and _extract_log_sections to confirm that gap.

First pass hardcoded a flat retry tail_lines guess. Fixed it to use the log's own original_length (capped) instead, since that is what the issue asks for. Extracted one _fetch_job_log helper so the retry does not duplicate the initial fetch. No behavior change outside the truncated-plus-step-missing case.

Checklist before requesting a review

• I have added proper PR title and linked to the issue
• I have performed a self-review of my code
• I can explain the purpose of every function, class, and logic block I added
• I understand why my changes work and have tested them thoroughly
• I have considered potential edge cases and how my code handles them
• If it is a core feature, I have added thorough tests
• My code follows the project's style guidelines and conventions

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[github-actions]

Greptile code review

This repo uses Greptile for automated review. Before merge, aim for Confidence Score: 5/5 with zero unresolved review threads — see CONTRIBUTING.md.

Run a review — add a PR comment with:

@greptile review

Give it ~5-10 minutes (sometimes longer) for results, then fix feedback and re-trigger until you reach Confidence Score: 5/5.

Optional: automate with the greploop skill.

[greptile-apps]

Greptile Summary

Adds truncation metadata and a one-shot larger-tail retry when a requested GitHub Actions step is missed after log truncation, and fixes ungrouped-only logs so step_number no longer pretends to match a fake section.

• get_github_actions_step_log exposes truncated, returned_length, and original_length.
• On truncated full-log fallback, retries once with line count estimated from char density (floor 5000, cap 20000).
• _extract_log_sections returns no sections when there are zero ##[group] markers; tests cover truncation, retry, and ungrouped step_number.

Confidence Score: 5/5

Safe to merge; the prior character-vs-line retry sizing issue is addressed and no blocking failures remain.

Retry now estimates line count from the returned tail’s character density before calling tail_lines, with floor and cap; ungrouped-only and truncation paths are covered by tests.

Important Files Changed

Filename	Overview
integrations/github/tools/actions.py	Truncation signaling, char-to-line retry sizing, shared fetch helper, and ungrouped-log section fix.
tests/tools/test_github_actions_tool.py	Regression coverage for ungrouped step_number, truncation fields, and retry-on-miss.

_{Reviews (2): Last reviewed commit: "Fix retry tail_lines to estimate lines, ..." | Re-trigger Greptile}

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[muddlebee]

@larsspinetta12 pls review

[larsspinetta12]

@greptile review again

[larsspinetta12]

@sahilnyk
Looks good overall:

• truncation metadata in the payload
• retry with a larger tail before accepting full-log
• ungrouped-only step_number=1 now correctly reports full-log

Two small things to fix below:
1. Inline issue 1 — length semantics --> On returned_length / original_length:
Problem: the issue asked for returned/total line counts, but these are character lengths (len(log_text) + MCP original_length). That’s fine if MCP reports chars, but please either:

• rename to something like returned_chars / original_chars, or
• document in the payload/tool description that these are characters, not lines,
  so agents don’t treat them as line counts when sizing a follow-up fetch.

Inline issue 2 — silent retry failure --> On the if retry_error is None: block:
Problem: if the retry fetch fails, we silently keep the truncated first response. Consider adding retry_attempted: true and/or retry_error so the agent can tell “we tried a larger window and it failed” vs “step really wasn’t there.”

@ me in a comment here when those are done!

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[sahilnyk]

@larsspinetta12 added those, please review!

[Davidson3556]

Nice fix — returning [] for the ungrouped case is the right root cause, and surfacing retry_error is a good touch.

One real issue: truncated will false-positive. _extract_log_text strips the tail but original_length is unstripped, so any complete log ending in a newline reports truncated=True — and when the step isn't found, that fires a wasted second fetch. Compare against the unstripped length instead.

Also: original_length isn't referenced anywhere else in the repo — can you confirm the pinned github-mcp-server version actually returns it? Otherwise the retry silently no-ops. A test for the missing-field case would pin that down.

lastly fix merge conflict

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[sahilnyk]

@Davidson3556 Addressed your suggestions and fixed them, please review again.