feat: implement comment persistence with unique HTML markers

[AnkanSaha]

Summary

This PR introduces the postOrUpdateComment utility to avoid spamming Pull Requests with multiple comments. Instead of creating a new comment for every run, the bot now looks for a unique hidden HTML marker and updates the existing comment if found.

Changes

• src/github/index.js: Added postOrUpdateComment function which fetches PR comments and checks for a specific marker string.
• src/index.js: Replaced postComment with postOrUpdateComment across all analysis steps (Review, Performance, Security, Quality, Best Practices, and Recommendations).
• Unique Markers: Added specific HTML comment tags for each section to allow targeted updates.
• Version Bump: Updated version from v5.18 to v5.19.

Verification

• Tested by triggering the bot on the same PR multiple times.
• Verified that existing comments are updated with new content instead of creating duplicates.
• Verified that if no comment exists, a new one is created correctly.

[github-actions]

🤖 Review Buddy - General Code Review

👥 Attention: @AnkanSaha

Oho @AnkanSaha! Maan gaye bhai, tune toh 're-inventing the wheel' ko naya matlab de diya. Ye postOrUpdateComment feature toh badhiya hai, par implementation? Bilkul waisi hi hai jaise 500m door dukan pe jaane ke liye tum flight pakad rahe ho.

Har comment ke liye tum poori list fetch kar rahe ho? Bhai, GitHub API tumhare baap ki jagah nahi hai ki unlimited requests bhejte rahoge. Ek hi PR mein 6 baar same comments fetch kar rahe ho—Review, Performance, Security, Quality, Best Practices, and Recommendations ke liye. Matlab efficiency ki toh tumne 'Gangs of Wasseypur' wali halat kar di hai.

Aur ye VERSION file manually update karna? Kya zamana hai, npm version naam ki bhi koi cheez hoti hai duniya mein.

Code Quality Score: 3/10 (Sirf isliye kyunki code chalta hai, par dimaag nahi lagaya gaya).

---

Generated by Review Buddy | Tone: roast | Language: hinglish

[github-actions]

⚡ Review Buddy - Performance Analysis

👥 Attention: @AnkanSaha

Arre bhai bhai bhai! Ye performance analysis dekh ke toh mere processor mein dard hone laga hai. Chalo, line-by-line tumhari 'kaari-gari' dekhte hain:

1. The N-Requests Disaster:
   Tumhare src/index.js mein Step 2 se Step 7 tak, tumne 6 baar postOrUpdateComment call kiya hai.
   Andar ki baat ye hai ki har call ke andar await fetchPRComments(repo, prNum, token) ho raha hai.
   Maths aati hai? 6 calls = 6 API Requests. Agar ek PR pe 100 comments hain, toh tum 600 comments fetch kar rahe ho bina kisi wajah ke.
   GitHub API Rate limits (5000/hr for PAT) ko tum toh nashte mein kha jaoge agar bade repo pe ye chala diya toh.

2. Algorithm ki 'Efficiency':
   comments.find(c => c.body && c.body.includes(marker))
   Har baar poori array iterate kar rahe ho. O(N) complexity hai search ki, aur tum use loop mein daal ke O(M * N) bana rahe ho jahan M steps hain.
   Ideally, tumhe comments ko ek baar fetch karke ek Map ya Object mein store kar lena chahiye tha jahan key tumhara 'marker' hota.

3. Memory Bloat:
   fetchPRComments saare comments ka data (author, timestamps, metadata) memory mein laata hai.
   Tum sirf body aur id check kar rahe ho. 6 baar ye bulky array memory mein load karna memory leaks ko 'invite' karne jaisa hai.

4. Blocking I/O:
   Tumhare calls sequential hain (await). Jab tak ek comment fetch-check-update nahi hota, doosra shuru nahi hota.
   Ye poora process 'async' toh hai par 'parallel' nahi.

Actionable Recommendation:

// Aise karo, thoda dimaag lagao
async function handlePullRequest(...) {
  const allComments = await fetchPRComments(GITHUB_REPOSITORY, prNumber, GITHUB_TOKEN);
  // Ek baar fetch karo aur filter kar lo markers ke basis pe
  
  const commentMap = allComments.reduce((acc, c) => {
     // Identify markers and map them
     if (c.body.includes('<!-- Review Buddy Start -->')) acc.review = c;
     // ... add others
     return acc;
  }, {});

  // Ab seedha update ya post karo bina re-fetching ke
}

Bhai, software engineer bano, API ka dushman nahi. Ye code dekh ke lagta hai tumne 'Cloud' ko sirf baarish ke liye samjha hai, computing ke liye nahi.

---

Generated by Review Buddy | Tone: roast | Language: hinglish

[github-actions]

🔐 Review Buddy - Security Audit

👥 Attention: @AnkanSaha

Security ke naam pe toh tumne 'Welcome' movie ke Majnu Bhai wali painting bana di hai.

1. Marker Injection (Low-Medium Severity):
   Tumhara marker ek simple string hai <!-- Review Buddy Start -->. Agar kisi 'shatir' user ne PR description mein ya kisi comment mein ye marker daal diya, toh tumhara bot confuse ho jayega. Wo us random comment ko update karne ki koshish karega.
   Remediation: Hamesha check karo ki comment ka author tumhara bot hi hai ya nahi (c.user.type === 'Bot').

2. Token Exposure Risk:
   postOrUpdateComment mein tum token pass kar rahe ho har jagah. Agar kahin bhi logInfo mein marker ya body ke saath token leak hua (kisi accidental print statement se), toh game over.

3. HTML Comments as Markers:
   <!-- marker --> use karna standard toh hai, par GitHub ke markdown parser mein ye kabhi-kabhi strip ho jaate hain agar sanitize kiya jaye. Better hai ki tum metadata API use karo ya phir koi aur robust way.

4. No Rate Limit Handling:
   Agar GitHub 403 Forbidden (Rate Limit Exceeded) bhejta hai, toh tumhara code phat jayega. Koi retry logic ya back-off mechanism nahi hai.
   Severity: Medium.
   OWASP Reference: A10:2021 – Server-Side Request Forgery (SSRF) ya API Abuse scenarios mein isko count kar sakte hain.

---

Generated by Review Buddy | Tone: roast | Language: hinglish

[github-actions]

📊 Review Buddy - Code Quality & Maintainability Analysis

👥 Attention: @AnkanSaha

🎯 Overall Benchmark: 45/100 (Poor)

Quality? Woh kya hota hai? Lagta hai Ankan bhai ne SOLID principles ko 'SOLO' principles samajh liya hai - 'Main akela hi sab ganda code likhunga'.

1. DRY (Don't Repeat Yourself) ki Maut:
   src/index.js mein tumne har step (Review, Performance, Security etc.) ke liye wahi boilerplate code repeat kiya hai:
   const comment = ...; await postOrUpdateComment(...);
   Bhai, ek simple loop chala dete steps ka array bana ke? Programmer ho ya copy-paste machine?

2. Hardcoded Markers:
   Ye markers <!-- Review Buddy Start --> poore code mein bikhre hue hain. Kal ko marker change karna hua toh 10 jagah change karoge? Ek constants file bana lo, warna dev team tumhara 'welcome' belan se karegi.

3. Error Handling (Zero/Nil/Sannata):
   fetchPRComments fail hua toh? updateComment fail hua toh? Tumhare code mein ek bhi try-catch nahi hai is naye function ke liye. Agar ek update fail hua, toh baaki saare steps skip ho jayenge.
   'Fail gracefully' suna hai? Tumhara code toh 'Fail dramatically' kar raha hai.

4. Naming Conventions:
   marker? Thoda aur descriptive ho sakta tha. botHiddenIdentifier ya kuch aisa.

5. Version Management:
   VERSION file ko manually v5.19 karna... bhai automation ke zamane mein tum manual labor kar rahe ho? CI/CD pipeline mein isko automate karo.

6. Function Signature:
   postOrUpdateComment(repo, prNum, body, marker, token)
   Itne saare arguments? Ek object pass karo ({ repo, prNum, body, marker, token }). Agli baar argument order bhool gaye toh debug karte karte baal jhad jayenge.

Refactoring Suggestion:

const STEPS = [
  { key: 'review', marker: '<!-- Review Buddy Start -->' },
  { key: 'performance', marker: '<!-- Review Buddy Performance -->' }
  // ... etc
];

for (const step of STEPS) {
  const content = getCleanedContent(step.key);
  await postOrUpdateComment(repo, prNum, `${content}${footer}`, step.marker, token);
}

Isse code 100 line se 20 line ka ho jayega. Par tumhe toh lines badhani hain, shayad LOC (Lines of Code) pe salary milti hai?

---

Generated by Review Buddy | Tone: roast | Language: hinglish

[github-actions]

💡 Review Buddy - Best Practices & Alternative Suggestions

👥 Attention: @AnkanSaha

Bhai, coding standards ki toh tumne 'Lagaan' waali team bana di hai. Dekho kaise sudhaar sakte ho:

1. Guard Clauses

Current Code:

if (!body) return;

Better Alternative:

if (!body || body.trim() === '') {
  logWarn('Empty body, skipping comment operation.');
  return;
}

Why: Sirf falsy check kafi nahi hai, empty strings bhi handle karo.

2. Logical Separation of Concerns

Current Code:
postOrUpdateComment fetches, finds, and updates.
Better Alternative:
Separate the finding logic from the action logic. Let index.js handle the 'what' and github/index.js handle the 'how'.

3. Template Literals vs String Concatenation

Current Code:

const comment = `... ${cleanedReview} ${footer}`;

Why: Template literals are fine, but try to avoid the massive blocks in index.js. Use a generator function.

4. Search Method

Current Code:
c.body.includes(marker)
Better Alternative:
c.body.startsWith(marker) or a Regex /^<!-- marker -->/.
Why: includes can match anywhere. Agar kisi ne quote kiya tumhara comment, toh tum use update kar doge. startsWith ya markers ko top pe rakhna zyada safe hai.

5. Constants for Markers

Current Code:
'<!-- Review Buddy Start -->'
Better Alternative:

const MARKERS = {
  REVIEW: '<!-- Review Buddy Start -->',
  PERFORMANCE: '<!-- Review Buddy Performance -->',
  // ...
};

Why: Centralized control. Ek jagah change, har jagah change.

---

Generated by Review Buddy | Tone: roast | Language: hinglish

[github-actions]

⚠️ Review Buddy - Final Recommendation

👥 Attention: @AnkanSaha

Recommendation: REQUEST CHANGES

Changes chahiye, bhai! Abhi approve nahi kar sakte.

Reasoning:

• API Efficiency Disaster: Calling fetchPRComments 6 times per PR run will hit rate limits instantly on busy repos.
• Lack of Caching: Comments should be fetched once and indexed by marker in a Map/Object.
• Redundant Code: Massive repetition in index.js for each analysis step; should be refactored into a loop.
• Incomplete Search Logic: Does not verify if the comment belongs to the bot, risking updating user comments that happen to contain the marker string.
• No Error Handling: The new postOrUpdateComment function lacks try-catch blocks, making the entire flow fragile.

---

📋 Review Checklist for Reviewers:

• Code changes align with the PR description
• No security vulnerabilities introduced
• Performance considerations addressed
• Code follows project conventions
• Tests are adequate (if applicable)
• Documentation updated (if needed)

🎯 Next Steps:

⚠️ Pehle suggestions address karo, phir approve karna.

Generated by Review Buddy | Tone: roast | Language: hinglish