Summary

tod pr get-code-comments <pr> can return fewer threads than actually exist on a pull request, with no error, warning, or count mismatch indicator — some threads are just silently missing from the JSON array.

Reproduction (public, on this server, so anyone can check)

• onedev/server PR 86: tod pr get-code-comments 86 returns 1 thread; the PR's code comments page shows 4.
• onedev/server PR 98: tod pr get-code-comments 98 returns 4 threads; the code comments page shows 13.

Ruled out: rebased/unreachable anchor commits. For PR 86 I fetched history and confirmed with git merge-base --is-ancestor that every dropped comment's anchor commit (not just the surviving one) is still an ancestor of the PR's head commit.

Root cause

PullRequestHelper.getCodeComments (server-core/src/main/java/io/onedev/server/ai/PullRequestHelper.java, ~lines 226–245): for a comment whose mark.getCommitHash() isn't the PR's current head, the method tries to re-map the comment's line range onto head via DiffUtils.mapLines/mapRange. When mapRange returns null — the same condition the web UI surfaces as "commented code is outdated" — the comment is just skipped:

if (mappedRange == null)
    return;

...instead of being added to the result with some fallback. So any comment OneDev itself would show as "outdated" is invisible to this API instead.

Impact

Any consumer of this endpoint (including AI agents driven by the shipped skills) can silently miss real, unresolved review comments, with nothing indicating something was omitted. This is worse than surfacing a stale comment — it looks like there's nothing to review when there is.

Suggested direction

Rather than dropping the comment, either return it with its original (un-remapped) position/commit hash, or add an explicit "outdated": true flag — mirroring how the web UI still surfaces these instead of hiding them.