alibaba / alibaba/open-code-review
`ocr review --timeout` does not extend the five-minute LLM request deadline
- Dominant language
- Go
- Stars
- 24.4k
- Forks
- 1.8k
- Avg merge
- 1d 19h
- Merged PRs (30d)
- 116
Description
## Environment
- `open-code-review v1.11.3` (`b3badd376`), darwin/arm64
- JSON agent-mode range review
- One selected Rust file, `zai-anthropic` provider, `glm-5.3`, concurrency 1
## Reproduction
Run a single-file review with an outer timeout larger than five minutes:
```sh
ocr review \
--audience agent \
--format json \
--provider zai-anthropic \
--model glm-5.3 \
--concurrency 1 \
--timeout 30 \
--from BASE \
--to HEAD \
--exclude 'all,other,changed,files'
```
The selected file was 291 lines. Planning completed on the first run, but the main request failed after exactly five minutes. The manifest reported:
```json
{
"classification": "timeout",
"reason": "file review exceeded its time limit",
"duration_to_headers_ms": 300002
}
```
Resuming the session with the same `--timeout 30` started planning again rather than reusing the completed plan. That planning request also failed at exactly five minutes before OCR moved to the main request.
Grouped reviews showed the same `duration_to_headers_ms` of about 300,000 ms despite `--timeout 600`.
## Expected behavior
`--timeout`, documented in minutes as the concurrent task timeout, should either:
1. apply to the provider request deadline needed to complete that task, or
2. document the independent five-minute provider-request ceiling and retry requests that time out before the task deadline.
A resume should reuse a completed plan when the file's main review was the failed stage.
## Impact
A review can repeatedly fail to cover one changed file even when the caller grants a larger task timeout. The JSON correctly marks coverage as failed, but there is no CLI setting that allows the file review to finish.
Contributor guide
Research direction
Start by tracing the `ocr review` command's `--timeout` handling through provider requests, planning, and the resume path; compare the task timeout with the observed five-minute deadline in the manifest. Reproduce the single-file and grouped-review cases, then verify that a larger timeout is honored or its independent ceiling is documented and that a failed main review reuses a completed plan.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- api, cli
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100