bug(issues): list labels_filter is silently ignored - returns the full unfiltered issue list #142

New issue

Closed

opened 2026-07-16 00:41:49 +00:00 by hexajon · 0 comments

hexajon commented

2026-07-16 00:41:49 +00:00

(Migrated from codeberg.org)

Observed (2026-07-15, MCP madt_issues on sixfold_space/madtea)

madt_issues action=list state=all labels_filter=<X> limit=50 returned the identical, complete, UNFILTERED issue list ("Showing 50 of 134") for every filter tried:

labels_filter=release-prep (label name)
labels_filter=status/launch-gated (scoped label name)
labels_filter=1974638 and labels_filter=1974644 (label IDs)

All four responses were byte-identical to an unfiltered list. The raw API passthrough proves the backend filter works: madt_api_call GET /repos/{owner}/{repo}/issues?labels=release-prep&state=all returned exactly the 8 correct issues. So the typed list path drops/never forwards the labels param.

Why this is nasty

A silently-ignored filter is worse than an error: the caller believes they are looking at "all issues with label X" and makes decisions on the full backlog instead. This is the same defect class as #127 (params swallowed instead of erroring), except here the param is fully applicable to the action - it just doesn't reach the request.

Asks

Fix labels_filter on the issues list path (CLI --labels too if it shares the plumbing - verify both surfaces).
Regression test: list with a label filter against a fixture where the filter must reduce the result set; assert the reduction (not just a 200).
While there: audit the other list filters (milestone_filter, assignee, mentioned_by, created_by, since/before already had #91/#107) for the same forward-the-param gap.

Acceptance

labels_filter by name and by ID both narrow the list on CLI and MCP.
A dropped/unforwardable filter param errors instead of silently returning everything.
Gate green.

## Observed (2026-07-15, MCP madt_issues on sixfold_space/madtea) `madt_issues action=list state=all labels_filter=<X> limit=50` returned the identical, complete, UNFILTERED issue list ("Showing 50 of 134") for every filter tried: - `labels_filter=release-prep` (label name) - `labels_filter=status/launch-gated` (scoped label name) - `labels_filter=1974638` and `labels_filter=1974644` (label IDs) All four responses were byte-identical to an unfiltered list. The raw API passthrough proves the backend filter works: `madt_api_call GET /repos/{owner}/{repo}/issues?labels=release-prep&state=all` returned exactly the 8 correct issues. So the typed list path drops/never forwards the labels param. ## Why this is nasty A silently-ignored filter is worse than an error: the caller believes they are looking at "all issues with label X" and makes decisions on the full backlog instead. This is the same defect class as #127 (params swallowed instead of erroring), except here the param is fully applicable to the action - it just doesn't reach the request. ## Asks 1. Fix `labels_filter` on the issues list path (CLI `--labels` too if it shares the plumbing - verify both surfaces). 2. Regression test: list with a label filter against a fixture where the filter must reduce the result set; assert the reduction (not just a 200). 3. While there: audit the other list filters (`milestone_filter`, `assignee`, `mentioned_by`, `created_by`, `since`/`before` already had #91/#107) for the same forward-the-param gap. ## Acceptance - `labels_filter` by name and by ID both narrow the list on CLI and MCP. - A dropped/unforwardable filter param errors instead of silently returning everything. - Gate green.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sixfold-space/madtea#142

No description provided.

Rows
Columns