← Back to issue list

Linter service clears lint results too greedily

View original Github issue

Metadata

Project
craft-application
Number
#1127
Type
issue
State
open
Author
bepri
Labels
—
Created
Updated
Closed
—

Current evaluation

LinterService.run() clears _issues/_issues_by_linter on every call, so a PRE run's results are lost when POST runs later and summary() can wrongly return OK. Filed by maintainer; still reproducible at HEAD.

Suggested action: keep open

Reason: The reported behaviour is still present in the code: craft_application/services/linter.py calls `self._issues.clear()` and `self._issues_by_linter.clear()` at the top of `run()`, so `summary()`/`get_highest_severity()` reflect only the last stage run, matching the issue's claim of possible false 0 return codes. The bug is valid and pinpointed by a maintainer, though there are no labels, comments, or a supplied reproducer, and the fix direction is under-specified (per-stage clearing vs. a combined pre+post `run()` API), which is why actionability is not higher.

Evaluated by: mr-cal-bot

Impact: 45 Quick Win: 17 Complexity: 45 Confidence: 78 Actionability: 70

Issue body

### Bug Description When implementing a full lint lifecycle, both pre and post linters are run on an artifact. This requires `LinterService.run()` to be called twice, since each stage must be invoked individually (`LinterService.run(Stage.PRE, ctx); LinterService.run(Stage.POST, ctx)`). This means: - Lint results are broken up in a manner that appears arbitrary to users; pre/post really are implementation details. - `LinterService.summary()` forgets the results of the first run, which could result in false positives for `0` return codes. ### To Reproduce Implement two custom linters, one pre- and one post-, and then try to run both of them as you might during a pack command's final steps. ### part yaml ```shell N/A ``` ### Relevant log output ```shell N/A ```

Evaluation history

Date Model Scores Action Summary
stealth/space-bunny-alpha
Impact: 45
Quick Win: 17
Complexity: 45
Confidence: 78
Actionability: 70
keep open LinterService.run() clears _issues/_issues_by_linter on every call, so a PRE run's results are lost when POST runs later and summary() can wrongly return OK. Filed by maintainer; still reproducible at HEAD.
stealth/space-bunny-alpha
Impact: 58
Quick Win: 26
Complexity: 42
Confidence: 77
Actionability: 78
needs triage Valid, unlabelled bug report: LinterService discards earlier lint results across separate PRE and POST runs, so summaries can incorrectly report success.
qwen3.6-35b-a3b-mtp-q6
Impact: 55
Quick Win: 41
Staleness: 65
Complexity: 25
Confidence: 75
Support Request: 15
needs triage LinterService.run() clears collected issues on each call, losing PRE stage results when POST is also run. Valid bug, untriaged for 53 days.
qwen/qwen3.6-35b-a3b
Staleness: 10
Complexity: 40
Confidence: 85
Support Request: 5
needs triage LinterService.run() clears results when called for PRE and POST stages, causing LinterService.summary() to lose data and produce incorrect return codes. Awaiting triage.
qwen3.6-35b-a3b-mtp-q6
Staleness: 5
Complexity: 40
Confidence: 85
Support Request: 5
needs triage Bug report describing how LinterService.summary() discards pre-stage lint results when run() is called twice, causing false zero return codes. Unlabelled and awaiting maintainer triage.

Update history

No update history recorded yet.

Related work

  • Caused By: canonical/craft-application#907 (confidence 80%)

    The linter service was introduced in commit a76bcaa6 'feat(services/linter): add a linter service (#907)', which added the unconditional clear() in run() that discards earlier-stage results.

Related issues

No related issues found above the similarity threshold.