ocr timed out and failed for some files, but status code=0

[vlotorev]

OpenCodeReview Version

v1.9.8 (9c5e90d) linux/amd64

Operating System

Linux (x86_64)

Installation Method

GitHub Release binary

LLM Provider

Other OpenAI-compatible endpoint

Bug Description

When ocr is run with --timeout set and timeout happens I expect that ocr would finish with non-zero return code.

Having non-zero return code is critical for detecting ocr and CI harness misconfiguration on CI.

Steps to Reproduce

Set timeout and run on slow LLM:

$ ocr review --commit HEAD --concurrency 1 --timeout 10 --audience agent
[ocr] Summary: 2 file(s) reviewed, 0 comment(s), ~251232 token(s) used (input: ~232407, output: ~18825), cache(read: ~200118, write: ~0), 10m48s elapsed
[ocr] Session: 496b007a-1dc5-4a77-8b71-aaeb928f9e13
Review partially complete: 0 finding(s); 1 of 2 selected item(s) failed.

LLM retry report: 0/16 requests retried, 0 retries, 0 recovered, 1 failed, 0 cancelled
- myfile.c / main_task #13: timeout -> failed


$ echo $?
0

Expected Behavior

$ echo $?
1

Logs / Error Output

Additional Context

No response

[Qiyuanqiii]

Thanks for the report. I was able to reproduce this locally: when a review ends in a partial state because a selected item times out, the CLI still publishes the partial result but currently exits with status 0.

I have identified the aggregate exit-status logic as the cause and am working on a fix so operational per-item failures, including timeouts, return a non-zero status while the partial review output remains available. I will follow up with the patch and validation results.

[crestonepeaks]

Thanks for reporting and reproducing this. We have not independently reproduced the exact partial-result/exit-0 path, but this behavior has a concrete downstream impact on our GitHub Actions rollout.

Our real OpenCodeReview canary reviews have taken roughly 15 to 20 minutes per selected file, so a multi-file review can realistically encounter a per-item timeout or operational failure. Because an overall successful job status does not currently prove that every selected item completed, our verification now reads the terminal review manifest and requires all selected items to be present in completed, with failed, waived, and coverage.failed all empty. We also keep the reviewer advisory rather than required.

We are deferring expansion into larger, more complex multi-file repositories until the fix in #1030 is reviewed, merged, included in an official release, and proven canary-first. We would love to see #1030 move forward.

[Qiyuanqiii]

I’m uncertain where the maintainer stands regarding #1030, as no comment has been posted yet.

[Qiyuanqiii]

@lizhengfeng101 Could we have a discussion about this issue and its corresponding PR? 🤔

[crestonepeaks]

Additional synthetic reproduction on official npm v1.11.5 (also reproduced on v1.9.10): four small Go files in a disposable two-commit repository, a localhost simulated OpenAI-compatible endpoint, concurrency 1, and OCR_NO_UPDATE=1. No real source or paid model traffic was used.

When one selected item receives a permanent HTTP 402 response and the other three finish, the terminal JSON correctly reports status: partial, four selected, three completed, one failed, and zero waived, but the CLI exits 0. With all four items receiving HTTP 402, it exits 1. A separate streaming case that sends HTTP 200 and an initial chunk, then stalls past the configured request timeout, also produces three completed/one failed with exit 0 in both versions.

Executing the unmodified official action's configuration/review shell blocks with these simulated partial results wrote OCR_EXIT_CODE=0; no posting step was executed. This reinforces that exit status alone cannot establish complete review, and confirms the partial-failure path remains present in v1.11.5. These local shell tests do not claim full hosted-action or runner-cancellation coverage.

This adds a current-release reproduction to the earlier downstream impact report. We can help with a focused upstream regression-test contribution if useful.