fix(#890): handle None parent in GitlabComment.add_reaction

[fullsend-ai-coder]

Summary

• Fix AttributeError crash in GitlabComment.add_reaction() when _parent is None and a duplicate award emoji race condition is encountered
• Guard the _parent access in the exception handler and fall back to the raw GitLab client (self._raw_comment.manager.gitlab.user.username) to resolve the current user
• Pass parent=self in get_comment() for both GitlabIssue and GitlabPullRequest so comments constructed through ogr always have a parent reference

Root Cause

When multiple workers add the same emoji reaction concurrently, GitLab returns a GitlabCreateError ("Award Emoji Name has already been taken"). The recovery path in add_reaction() tried to find the existing reaction by looking up the current user via self._parent.project.service.user.get_username(). If _parent was None (comment constructed without a parent argument), this crashed with AttributeError: 'NoneType' object has no attribute 'project'.

Changes

• ogr/services/gitlab/comments.py: Add None guard on self._parent with fallback to raw GitLab client for username lookup
• ogr/services/gitlab/issue.py: Pass parent=self in get_comment()
• ogr/services/gitlab/pull_request.py: Pass parent=self in get_comment()
• tests/unit/test_gitlab.py: Add unit tests covering duplicate emoji handling with and without parent, plus success path

Testing

• All 122 unit tests pass
• New tests verify: duplicate emoji with _parent=None (the crash scenario), duplicate emoji with _parent set, and normal success path
• Ruff linter passes on all changed files

---

Closes #890

Post-script verification

• Branch is not main/master (agent/890-fix-add-reaction-none-parent)
• Secret scan passed (gitleaks — 8a9787200dc24411e2e0294178c6def0cbb3bbef..HEAD)
• PR body secret scan passed (gitleaks — no-git)
• Pre-commit hooks passed (authoritative run on runner)
• Tests ran inside sandbox

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 5:04 PM UTC · Completed 5:20 PM UTC
Commit: 259d0b2 · View workflow run →

[centosinfra-prod-github-app]

Build succeeded.
https://gateway-cloud-softwarefactory.apps.ocp.cloud.ci.centos.org/zuul/t/packit-service/buildset/4c0e219b8e2f4c43ab5d9fa8c8945e2b

✔️ pre-commit SUCCESS in 3m 21s
✔️ ogr-tests-pip-deps SUCCESS in 11m 40s

[fullsend-ai-review]

Review

Findings

Low

• [edge-case] ogr/services/gitlab/comments.py:88 — The fallback path self._raw_comment.manager.gitlab.user.username assumes Gitlab.auth() was called (populates gitlab.user). If gitlab.user is None (no token), this would raise AttributeError. This is a pre-existing issue — the _parent path has the same assumption — and reactions require authentication, making the scenario unlikely in practice.

• [API-shape-consistency] ogr/services/github/issue.py — The PR fixes Gitlab's get_comment() to pass parent=self, but GitHub's get_comment() (GithubIssueComment in issue.py and GithubPRComment in pull_request.py) and Pagure's get_comment() still use positional-only args without parent. This is cosmetic today — neither service's add_reaction() accesses _parent — but creates a cross-service inconsistency. Forgejo already passes parent=self. Consider a follow-up to align all backends.

• [test-class-style] tests/unit/test_gitlab.py:21 — New TestGitlabCommentAddReaction uses a plain pytest-style class while existing TestGitlabService in the same file inherits from unittest.TestCase. Both styles exist in the broader test suite, so not a strict violation.

---

Labels: PR modifies ogr/services/gitlab/ exclusively — GitLab service bug fix

[fullsend-ai-review]

[low] edge-case

The fallback path self._raw_comment.manager.gitlab.user.username assumes Gitlab.auth() was called (populates gitlab.user). If gitlab.user is None (no token), this would raise AttributeError. This is a pre-existing issue — the _parent path has the same assumption — and reactions require authentication, making the scenario unlikely in practice.

[fullsend-ai-review]

[low] test-class-style

New TestGitlabCommentAddReaction uses a plain pytest-style class while existing TestGitlabService in the same file inherits from unittest.TestCase. Both styles exist in the broader test suite, so not a strict violation.