t1085: Increase AI reasoning timeout from 120s to 300s#1643
Conversation
Opus needs more than 120s to analyze 15KB+ of project context and produce a structured JSON action plan. The first successful AI response (2005 bytes of reasoning) was cut off mid-thought by the timeout. 300s (5 min) gives opus adequate time for complex analysis. Configurable via SUPERVISOR_AI_TIMEOUT env var.
Summary of ChangesHello @marcusquinn, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses an issue where AI reasoning processes were prematurely terminating due to insufficient timeout periods. By extending the default AI timeout, it ensures that AI models have adequate time to complete complex analyses and produce comprehensive, structured responses, thereby improving the reliability and completeness of AI-driven operations. Highlights
Changelog
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
WalkthroughThe AI session timeout in the supervisor script is increased from 120 to 300 seconds, with a comment explaining the change relates to Opus context size. Control flow and error handling logic remain unchanged. Changes
Estimated Code Review Effort🎯 1 (Trivial) | ⏱️ ~2 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
🔍 Code Quality Report�[0;35m[MONITOR]�[0m Code Review Monitoring Report �[0;34m[INFO]�[0m Latest Quality Status: �[0;34m[INFO]�[0m Recent monitoring activity: 📈 Current Quality Metrics
Generated on: Wed Feb 18 14:35:09 UTC 2026 Generated by AI DevOps Framework Code Review Monitoring |
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
The pull request effectively increases the AI reasoning timeout from 120 seconds to 300 seconds, addressing the need for the Opus model to have more time to process large contexts and produce structured JSON output. The change is clearly documented with an inline comment explaining the rationale. The modification is straightforward and aligns with the functional requirements described.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.agents/scripts/supervisor/ai-reason.sh (1)
146-153:⚠️ Potential issue | 🟠 MajorStale-lock threshold now equals the AI timeout — concurrent sessions possible.
With the timeout raised to 300 s, the condition
lock_age -lt 300on line 147 gives zero margin. A legitimate session that is still running at second 300 will havelock_age == 300, fail the< 300check, and be treated as stale even though the process is alive — letting a second reasoning session start concurrently.Previously (120 s timeout vs 300 s stale-guard) there was a comfortable 180 s buffer. That buffer is now gone.
🔒 Proposed fix — derive stale threshold from the timeout env-var
- # If lock holder is still alive and lock is not stale (< 5 min), skip - if kill -0 "$lock_pid" 2>/dev/null && [[ "$lock_age" -lt 300 ]]; then + # If lock holder is still alive and lock is not stale (timeout + 60s buffer), skip + local _lock_stale_threshold=$(( ${SUPERVISOR_AI_TIMEOUT:-300} + 60 )) + if kill -0 "$lock_pid" 2>/dev/null && [[ "$lock_age" -lt "$_lock_stale_threshold" ]]; thenThis keeps the threshold in sync with whatever value
SUPERVISOR_AI_TIMEOUTis set to, including when it is overridden via the environment.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.agents/scripts/supervisor/ai-reason.sh around lines 146 - 153, The stale-lock check uses a hardcoded 300s and the "< 300" test so a live process at exactly 300s is treated as stale; change the code to read SUPERVISOR_AI_TIMEOUT (defaulting to 300 if unset) into a variable (e.g., AI_TIMEOUT) and use that for the comparison, and treat equality as still-live (use -le "$AI_TIMEOUT" or equivalent) when checking lock_age against lock_pid/lock_file so the stale threshold follows the configured timeout and avoids concurrent sessions.
🧹 Nitpick comments (1)
.agents/scripts/supervisor/ai-reason.sh (1)
485-494:sedbracket extraction stops at the first], not the last.
sed -n '/\[/,/\]/p'prints from the first line containing[to the first line containing]. For a multi-line JSON array with nested arrays (e.g., a"tags"field), this truncates at the first closing bracket inside the payload, producing unparseable JSON.jqwill reject it and the fallback returns empty, so this degrades gracefully rather than silently corrupting — but it means Try 4 is effectively a no-op for any non-trivial response.♻️ More robust bracket extraction with Python/awk
- # Try 4: Find first [ and last ] in the response - local bracket_json - bracket_json=$(printf '%s' "$response" | sed -n '/\[/,/\]/p') - if [[ -n "$bracket_json" ]]; then - parsed=$(printf '%s' "$bracket_json" | jq '.' 2>/dev/null) - if [[ $? -eq 0 && -n "$parsed" ]]; then - printf '%s' "$parsed" - return 0 - fi - fi + # Try 4: Extract from first [ to matching last ] using Python for bracket-depth tracking + local bracket_json + bracket_json=$(printf '%s' "$response" | python3 -c " +import sys, json +text = sys.stdin.read() +start = text.find('[') +if start == -1: sys.exit(1) +depth, end = 0, -1 +for i, ch in enumerate(text[start:], start): + if ch == '[': depth += 1 + elif ch == ']': + depth -= 1 + if depth == 0: end = i; break +if end != -1: print(text[start:end+1]) +" 2>/dev/null || echo "") + if [[ -n "$bracket_json" ]]; then + parsed=$(printf '%s' "$bracket_json" | jq '.' 2>/dev/null) + if [[ $? -eq 0 && -n "$parsed" ]]; then + printf '%s' "$parsed" + return 0 + fi + fiThis tracks bracket depth, correctly handling nested arrays in tags, questions, etc.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.agents/scripts/supervisor/ai-reason.sh around lines 485 - 494, The sed range extraction using "bracket_json=$(printf '%s' \"$response\" | sed -n '/\\[/,/\\]/p')" stops at the first closing bracket and fails for nested arrays; change Try 4 to extract the JSON array by tracking bracket depth instead (e.g., use an awk or Python one-liner that reads "$response", finds the first '[' and then emits characters until matching the corresponding closing ']' accounting for nested brackets), assign that output back to bracket_json, then keep the existing parsed=$(printf '%s' "$bracket_json" | jq '.' 2>/dev/null) and checks; ensure you reference the same variables (response, bracket_json, parsed) so the subsequent jq parsing logic is unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In @.agents/scripts/supervisor/ai-reason.sh:
- Around line 146-153: The stale-lock check uses a hardcoded 300s and the "<
300" test so a live process at exactly 300s is treated as stale; change the code
to read SUPERVISOR_AI_TIMEOUT (defaulting to 300 if unset) into a variable
(e.g., AI_TIMEOUT) and use that for the comparison, and treat equality as
still-live (use -le "$AI_TIMEOUT" or equivalent) when checking lock_age against
lock_pid/lock_file so the stale threshold follows the configured timeout and
avoids concurrent sessions.
---
Nitpick comments:
In @.agents/scripts/supervisor/ai-reason.sh:
- Around line 485-494: The sed range extraction using "bracket_json=$(printf
'%s' \"$response\" | sed -n '/\\[/,/\\]/p')" stops at the first closing bracket
and fails for nested arrays; change Try 4 to extract the JSON array by tracking
bracket depth instead (e.g., use an awk or Python one-liner that reads
"$response", finds the first '[' and then emits characters until matching the
corresponding closing ']' accounting for nested brackets), assign that output
back to bracket_json, then keep the existing parsed=$(printf '%s'
"$bracket_json" | jq '.' 2>/dev/null) and checks; ensure you reference the same
variables (response, bracket_json, parsed) so the subsequent jq parsing logic is
unchanged.
1 participant
Summary
SUPERVISOR_AI_TIMEOUTfrom 120s to 300s (5 min)SUPERVISOR_AI_TIMEOUTenv varEvidence
From
reason-20260218-142828.md— first run with working--format default:--format textbug, now fixed in PR t1085: Fix --format text -> --format default for opencode run in AI reasoning #1642)Summary by CodeRabbit