Skip to content

fix(issue): removeIssueLabel rejects labels attached to the issue (#48) - #52

Merged
IamCoder18 merged 2 commits into
mainfrom
IamCoder18/cli-bug-issue-label-remove-errors-not-found-for
Aug 19, 2026
Merged

fix(issue): removeIssueLabel rejects labels attached to the issue (#48)#52
IamCoder18 merged 2 commits into
mainfrom
IamCoder18/cli-bug-issue-label-remove-errors-not-found-for

Conversation

@IamCoder18

Copy link
Copy Markdown
Owner

Fixes #48.

Bug

`huly issue label remove` rejected labels that were actually attached to the issue with `label not found`. The implementation first looked up the label in the workspace-level `tags:class:TagElement` catalog and bailed out if no catalog entry existed — but a label can be attached to an issue even when no matching `TagElement` row is in the catalog (e.g. imported from another client, seeded outside the catalog, or written via raw tx).

Repro (before fix)

```
$ huly issue label add HULY-4 --label security --label publication --label telemetry
$ huly issue get HULY-4 --json | jq .labels
["security","publication","telemetry"]
$ huly issue label remove HULY-4 --label publication
✗ error [2] label publication not found
```

Fix

Query `tags:class:TagReference` directly by `attachedTo = issue._id` + `title = `, which mirrors how labels are actually stored on the issue. The `TagReference` already carries `title`, so the catalog lookup is unnecessary. The "label not on issue" error message is preserved for the genuine not-attached case.

Tests

Added 4 unit tests in `packages/cli/src/resources/issue.test.ts`:

Verification

  • `pnpm test` → 469/469 pass
  • `pnpm typecheck` → clean
  • `pnpm format:check` / `pnpm lint` → clean

Acceptance criteria

  • ✅ `label remove` succeeds when the label is attached to the issue, regardless of workspace catalog state.
  • ✅ Error message still says "label not on issue" so the user understands the failure mode.

`huly issue label remove` was looking up the label in the workspace-level
`tags:class:TagElement` catalog first and throwing `label <name> not
found` when no catalog entry existed, even when the label was attached to
the issue (e.g. labels imported via another client or seeded outside the
catalog).

Query `tags:class:TagReference` directly by `attachedTo = issue._id` +
`title = <name>`, which mirrors how labels are actually stored on the
issue. Added 4 unit tests covering the original repro, orphan-label removal,
and the not-attached / not-found error paths.
@coderabbitai

coderabbitai Bot commented Aug 19, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

Warning

Review limit reached

@IamCoder18, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 6 minutes

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

Wait for the limit to reset, then comment @coderabbitai review or push new commits to the PR.

An organization admin can change what happens after included review limits in Billing.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 2d57eaa6-f554-4504-9663-79bfaae4c968

📥 Commits

Reviewing files that changed from the base of the PR and between 0fd0d33 and bb4182a.

📒 Files selected for processing (2)
  • packages/cli/src/resources/issue.test.ts
  • packages/cli/src/resources/issue.ts

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 9162b24c-91a3-4bec-8f1d-7defb1cd2fa7

📥 Commits

Reviewing files that changed from the base of the PR and between 7f12773 and 0fd0d33.

📒 Files selected for processing (3)
  • CHANGELOG.md
  • packages/cli/src/resources/issue.test.ts
  • packages/cli/src/resources/issue.ts

Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.

📜 Recent review details
⏰ Context from checks skipped due to timeout. (1)
  • GitHub Check: Kilo Code Review
🔇 Additional comments (4)
packages/cli/src/resources/issue.ts (1)

1376-1384: LGTM!

packages/cli/src/resources/issue.test.ts (2)

10-10: LGTM!


383-475: LGTM!

CHANGELOG.md (1)

94-101: LGTM!


📝 Walkthrough

Walkthrough

The CLI now removes issue labels through issue-specific TagReference records. Tests cover labels without catalog entries, orphaned references, retained labels, and not-found cases. The changelog documents the fix.

Changes

Issue label removal

Layer / File(s) Summary
Direct reference removal
packages/cli/src/resources/issue.ts
removeIssueLabel finds references by issue and label title, then removes them through the shared TagReference class.
Removal validation and documentation
packages/cli/src/resources/issue.test.ts, CHANGELOG.md
Tests cover catalog-independent removal, unrelated labels, orphaned references, and missing labels or issues. The changelog records the updated lookup behavior.

Estimated code review effort: 2 (Simple) | ~10 minutes

Merge Risk: ⚪ Minimal · up to 0fd0d

This localized fix removes attached labels without requiring a catalog entry while preserving the not-attached error behavior; no actionable merge-blocking risk remains after normal checks and review.

Possibly related PRs

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly identifies the issue fixed: label removal rejected labels attached to an issue.
Description check ✅ Passed The description directly explains the bug, implementation, tests, and acceptance criteria for issue label removal.
Linked Issues check ✅ Passed The implementation and tests satisfy issue #48 by removing attached labels regardless of catalog state and preserving a clear unattached-label error.
Out of Scope Changes check ✅ Passed The code, tests, and changelog changes directly support the linked issue and contain no unrelated scope.
✨ Finishing Touches 💡 1
📝 Generate docstrings 💡
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch IamCoder18/cli-bug-issue-label-remove-errors-not-found-for

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

if (!tag) throw new CliError(ExitCode.NotFound, `label ${labelName} not found`)
const refs = (await client.findAll('tags:class:TagReference' as Ref<Class<Doc>>, {
const tagRefClass = 'tags:class:TagReference' as Ref<Class<Doc>>
const refs = (await client.findAll(tagRefClass, {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SUGGESTION: The new findAll query no longer filters by collection: 'labels'. The old code filtered by tag: tag._id (TagElement ID), which would only match references to that specific TagElement. The new code filters by title: labelName, which could match TagReferences in other collections (e.g., 'components') attached to the same issue. If such a colliding reference exists, the subsequent removeCollection call (which targets 'labels') would fail or remove the wrong reference, and the loop would abort partway through. Consider adding collection: 'labels' to the query filter so orphan-label removal stays scoped to the label collection.


Reply with @kilocode-bot fix it to have Kilo Code address this issue.

@kilo-code-bot

kilo-code-bot Bot commented Aug 19, 2026

Copy link
Copy Markdown

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Overview

Severity Count
CRITICAL 0
WARNING 0
SUGGESTION 0

The previous review's SUGGESTION (missing collection: 'labels' filter on findAll) has been resolved in commit bb4182a: the filter is now present at packages/cli/src/resources/issue.ts:1379, and a regression test was added at packages/cli/src/resources/issue.test.ts:476-509 that verifies a TagReference with the same title but collection: 'components' is left untouched. No new issues found in the incremental diff.

Files Reviewed (2 files)
  • packages/cli/src/resources/issue.test.ts - 0 issues
  • packages/cli/src/resources/issue.ts - 0 issues
Previous Review Summary (commit 0fd0d33)

Current summary above is authoritative. Previous snapshots are kept for context only.

Previous review (commit 0fd0d33)

Status: 1 Issue Found | Recommendation: Address before merge

Overview

Severity Count
CRITICAL 0
WARNING 0
SUGGESTION 1
Issue Details (click to expand)

SUGGESTION

File Line Issue
packages/cli/src/resources/issue.ts 1377 findAll on TagReference no longer filters by collection: 'labels'; could match references in other collections attached to the same issue
Files Reviewed (3 files)
  • CHANGELOG.md - 0 issues
  • packages/cli/src/resources/issue.test.ts - 0 issues
  • packages/cli/src/resources/issue.ts - 1 issue

Fix these issues in Kilo Cloud


Reviewed by minimax-m3 · Input: 23.2K · Output: 2.2K · Cached: 131.3K

Address PR #52 review feedback. The previous fix queried
`tags:class:TagReference` by `attachedTo` + `title` alone, which could
match references in other collections (`'components'`, etc.) attached to
the same issue if they shared a title. The subsequent `removeCollection`
call targeting `'labels'` would then fail or remove the wrong reference,
aborting the loop partway through.

Add `collection: 'labels'` to the `findAll` filter so orphan-label
removal stays scoped to the label collection. Add a regression test that
verifies a non-label collection reference with the same title is left
untouched.
@IamCoder18

IamCoder18 commented Aug 19, 2026

Copy link
Copy Markdown
Owner Author

Addressed review feedback: added collection: 'labels' to the findAll filter in removeIssueLabel so the lookup can't accidentally pick up TagReferences in other collections ('components', etc.) that share a title. Added a regression test verifying the non-label collection reference is left untouched.

pnpm test → 470/470 pass.

@IamCoder18
IamCoder18 merged commit c585bd7 into main Aug 19, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

CLI bug: issue label remove errors 'not found' for labels attached to the issue

1 participant