Feature Request: Persistent Inline Comments to Prevent Duplicates

[arun131]

Feature request

I propose adding support for persistent inline comments, similar to how persistent comments work today.

Currently, when the agent runs multiple times on the same PR/MR, it posts duplicate inline comments for identical issues or suggestions. This creates unnecessary clutter in reviews — I’ve observed this behavior on GitLab in particular.

The solution would be to track existing inline comments (e.g., using GitHub’s comment IDs or content hashes) and avoid creating duplicates if a similar comment is already present.

Benefits:

Reduces noise in PR discussions, keeping reviews cleaner and more actionable.

Improves efficiency for iterative PRs where the agent runs multiple times (e.g., after fixes).

Aligns with enterprise needs in Qodo Merge for better suggestion tracking.

Motivation

I’m using the agent within a sophisticated workflow where a helper agent verifies adherence to internal code quality and guidelines. Based on file changes, multiple jobs are triggered to post reviews. In this setup, comments sometimes get posted repeatedly across runs, leading to unnecessary noise.

Thanks for considering this—excited about PR-Agent's potential!

[qodo-free-for-open-source-projects]

💡 Auto-generated documentation-based answer:

Thanks for the suggestion! Today, “persistent” behavior is supported for the main tool comments (not inline line comments):

• /review: pr_reviewer.persistent_comment=true (default)
• /improve (table comment): pr_code_suggestions.persistent_comment=true (default)
• /compliance, /checks, /describe-as-comment also have persistent_comment controls.

For inline code comments:

• Bitbucket and GitLab inline suggestions are supported, but the docs don’t state a de-duplication/persistence mechanism for identical inline comments across runs. As you observed, duplicates can occur when tools are re-run.

Noise-reduction workarounds you can use now:

• Prefer table mode for /improve (default) instead of inline committable comments, or use dual_publishing_score_threshold to only publish high-score items inline.
• Keep automatic runs minimal via pr_commands/push_commands and tune suggestions_score_threshold and suggestions_depth.
• Use persistent top-level comments (above) so updates edit a single comment instead of posting new ones.

Status: There’s no documented feature that de-duplicates existing inline comments by ID/content hash across runs. Your proposal (tracking IDs/content hashes and skipping duplicates) would be a useful enhancement—especially for GitLab. If you can share:

• Which tool(s) you run inline (/improve committable_code_suggestions, /implement, etc.)
• Provider and hosting (GitLab Cloud/Server; PR-Agent self-hosted vs Qodo Merge)
• Example PR links or screenshots
  it would help validate and scope the implementation.

Relevant Sources:

• https://qodo-merge-docs.qodo.ai//tools/review#configuration-options
• https://qodo-merge-docs.qodo.ai//tools/improve#configuration-options
• https://qodo-merge-docs.qodo.ai//usage-guide/automations_and_usage#qodo-merge-automatic-feedback
• https://qodo-merge-docs.qodo.ai//faq/index#-note-"q:-how-to-reduce-the-noise-generated-by-qodo-merge"
• https://qodo-merge-docs.qodo.ai//tools/improve#table-vs-committable-code-comments

[dbudwin]

This would be huge and is currently our main gripe with Qodo!

[mungo312]

Yes this would be great

[avidspartan1]

I have an AI-assisted implementation (meaning I primarily used Claude+Codex to code it) of this feature on my fork that seems to be working for GitHub Enterprise Server. I'm running it self-hosted with AWS Bedrock. I also (hopefully) fixed extended thinking for Sonnet 4.6, still verifying that.

If anyone else can give that a whirl to build some consensus before I submit a PR (I don't want to throw slop at this project), that'd be super.

[IsmaelMartinez]

We have a working GitLab implementation today using a SHA-256 fingerprint over (file, line, normalised first 80 chars) embedded as an HTML-comment marker in the suggestion body, with one discussions.list lookup per pipeline. Design is provider-agnostic; only the listing API differs between GitHub and GitLab. Soaking on a few internal MRs this week, will open an upstream PR if the dedup rate holds. Happy to coordinate with @avidspartan1.

[avidspartan1]

I'd be happy to give your implementation a try for GHES if you put up a PR, @IsmaelMartinez. Thanks!

[IsmaelMartinez]

I will let it cook for a few days. I might "pest" someone from qodo tomorrow in London as I can see they will be at the same conferences as me :D (LDX3)

[IsmaelMartinez]

Hi @avidspartan1, hope you're having a good week. I've opened #2424 implementing this: an opt-in persistent_inline_comments flag (off by default) for GitHub and GitLab. It embeds a hidden fingerprint marker in each inline comment and scans existing comments on later runs to skip duplicates, matching a text fingerprint OR a code-block fingerprint so a re-emitted finding is caught even if the wording or code shifts.

Honest on maturity: it has only been running since the start of this week, in our GitLab CI (enterprise GitLab with self-hosted runners, on an AWS Bedrock backend), and on GitLab only. The GitHub path is unit-tested but not yet run live, so testing on GHES would be especially valuable.

[avidspartan1]

Thanks, @IsmaelMartinez! I'll let the new PR bake in your environment for another week or so to stabilize, then I can give it a whirl for GHES.

[IsmaelMartinez]

Hi @avidspartan1, for context, it seems to be holding fine. So far 85 distinct MRs (gitlab call them MRs instead of PRs) and 221 comments (92 the general reviewer guide and 129 inline) and counting. Not a single duplicate so looking good. Appreciate a check on the github side of things. Thanks again!

[avidspartan1]

hey @IsmaelMartinez - looks like there is an issue with the code suggestion fingerprint getting emitted on GitHub (only the comment prose fingerprint is emitted for me on GHES). I'm investigating to see why that is the case :)

[avidspartan1]

It looks like the behavior occurs when a code suggestion doesn't have a valid hunk, and gets moved. See this commit for my fix (worked for me): avidspartan1@aefce47