Review Output Randomly Changes to Incorrect / Unrelated Reviews

[TejasGtech]

Bug: Review Results Randomly Change to Incorrect / Unrelated Reviews

Description

While testing git-lrc review, I noticed that the review output is unstable and sometimes changes unexpectedly after the initial review is generated.

The first review is often correct for the current file changes, but after a few moments the review content changes and starts showing:

• unrelated architecture summaries
• incorrect technical highlights
• reviews for code that does not exist in the current diff
• completely unrelated project descriptions

In some cases, the generated review is not even 1% related to the actual file content.

This appears to be either:

• stale diff/context reuse
• cached review contamination
• prompt/context leakage
• incorrect diff loading
• asynchronous review overwrite race condition

---

Steps to Reproduce

1. Create a very small Python file:

print("hello")
print("code review")qaww

2. Run:

git lrc review

3. Observe the generated review.

4. Initially, the review may look correct or partially correct.

5. After some time, the review content suddenly changes and shows unrelated summaries.

---

Expected Behavior

The review should consistently analyze only the current git diff/file changes.

Example expected review:

• simple print statement changes
• no major issues detected

---

Actual Behavior

The review suddenly changes into unrelated summaries such as:

• "Implement Async SQS Batch Processing for Lambda"
• AWS/S3/SQS architecture comments
• Lambda processing summaries
• unrelated backend/system descriptions

even though the actual file only contains simple print statements.

---

Screenshots / Evidence

Actual file content

print("hello")
print("code review")qaww

Incorrect generated review

The review generated unrelated AWS Lambda/SQS architecture summaries and multiple comments not related to the file.

| Review Output

| Code folder and terminal

| Video proof of crashing issue

git-lrc.problem.mp4

---

Possible Root Causes

• Previous review context being reused
• Cached diffs not cleared
• Prompt contamination
• Async review state overwrite
• Incorrect preloaded diff handling
• Shared review session memory

---

Environment

• OS: Windows 11
• VS Code terminal
• git-lrc CLI
• Review provider: Gemini API KEY

---

Additional Notes

This issue can reduce trust in the review system because unrelated reviews appear for very small/simple changes.

The problem seems more visible when:

• running multiple reviews
• reviewing tiny diffs
• re-running review commands quickly

[shrsv]

Looks like a serious issue, haven't noticed this before. Will check immediately.

[shrsv]

@TejasGtech - can you share your version number lrc --version. Also is it the first time you are facing this issue or have you faced before?

[TejasGtech]

@shrsv

Version: lrc version v0.3.7

This is the first time I am facing this issue. I am a new user and installed git-lrc today for testing after seeing the suggestion from “Meneshwar” on LinkedIn.

The first 3 to 5 reviews worked properly, but after trying multiple times, it started giving problems. I also tried changing the API key and created a new one, but the issues still remain.

[shrsv]

Ok, thank you for the details - this helps, we are actively debugging this, will update

[lovestaco]

An internal port conflict caused incorrect review data to be displayed when lrc was run multiple times in quick succession. The fix is in progress. Thanks for raising the issue.

[shrsv]

Update on our present thinking:

This could be happening due to multiple tabs/ports of git-lrc running parallelly.

We have multiple UI ports, and multiple backend ports. And a stale tab could be triggering requests to a newer internal backend port of git-lrc and messing up the state.

Since you mentioned triggering multiple reviewing quickly - perhaps some state conflicts getting triggered.

Also in Windows -- port handling is looser than in Linux -- so some potential issues there as well.

We found that in the backend "empty file" was submitted for main.py -- which can only happen when there's a client side data corruption - which is feasible via this port mismatch issue.

We are considering a client-side fix for this.

Also - if you can walk us through the issue sometime through a meet or something, that'll give us a sharper RCA as well.

But we will harden this from the client side further today itself.