Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[bug]: GitLab integration posts duplicate "Linked to Plane Work Item(s)" comments on MRs with more than 20 notes

Open Beginner friendly
  • Is something wrong?
#10,082 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
85/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
backend-api-design

Research direction

Start in packages/etl at the GitLab entry point and inspect GitLabService.getMergeRequestComments, then review its callers and existing tests. Update the notes request to follow pagination with a bounded page loop while preserving the endpoint order; done means merge requests with more than 20 notes reuse and update the existing Plane comment without creating duplicates.

Written by the indexing model from the issue text.

Description

Is there an existing issue for this?
  • I have searched the existing issues
Current behavior

On a self-hosted instance the GitLab integration posts a second (and later a third) Linked to Plane Work Item(s) comment on the same merge request, instead of reusing the one it already posted.

It only happens on merge requests that already carry more than ~20 notes. On merge requests with fewer notes the existing comment is correctly found and updated, so the behaviour looks fine until a merge request gets busy enough.

What I expect: the integration finds its own earlier comment and updates it, regardless of how many notes the merge request has.

Steps to reproduce
  1. Connect a GitLab project to a Plane project.
  2. Open a merge request whose branch name or title references a work item — the integration posts Linked to Plane Work Item(s).
  3. Let the merge request accumulate more than 20 notes. System notes ("added N commits", label changes, etc.) count here too, so this happens quickly on a normally reviewed merge request.
  4. Trigger another merge request event (push, edit, reopen).
  5. A duplicate Linked to Plane Work Item(s) comment appears.
Cause

GET /projects/:id/merge_requests/:iid/notes returns 20 items per page by default.

The notes are read in @plane/etl (packages/etl, gitlab entry point) by GitLabService.getMergeRequestComments, which performs a single GET on that endpoint with no query parameters. So it only ever sees GitLab's default first page — the 20 most recent notes. As soon as the original Linked to Plane Work Item(s) comment scrolls out of that window, the "have I already commented?" lookup finds nothing and a new comment is created. That matches the >20 notes threshold exactly.

Suggested fix

Paginate the request:

async getMergeRequestComments(projectId, mergeRequestIid) {
  const all = [];
  for (let page = 1; page <= 50; page++) {
    const batch = (
      await this.client.get(
        `/projects/${projectId}/merge_requests/${mergeRequestIid}/notes`,
        { params: { per_page: 100, page } },
      )
    ).data || [];
    all.push(...batch);
    if (batch.length < 100) break;
  }
  return all;
}

per_page=100 means this still costs a single request on the vast majority of merge requests; the page cap is only a guard against a runaway loop. Note that the callers sort/transform the result themselves, so returning the full list in the endpoint's own order keeps the existing behaviour intact.

Verified on a self-hosted instance: with pagination in place the duplicate comments stop appearing, including on merge requests with 30+ notes.

Environment

Production

Browser

Other (server side, no browser involved)

Variant

Self-hosted

Version

v3.3.3

Dominant language
TypeScript
Stars
61.1k
Forks
6.1k
Avg merge
1d 12h
Merged PRs (30d)
80

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from makeplane/plane

All issues in makeplane/plane

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.