Severity levels overview
There are four severity levels, ranked from most to least critical:Error
Critical issues that will cause crashes
Warning
Problems that should be fixed
Info
Suggestions for improvement
Hint
Minor style or optimization suggestions
Error severity
Priority: 4 (Highest) Errors represent critical issues that will cause your plugin to crash, fail to load, or behave incorrectly at runtime. These must be fixed before deploying your plugin.Common error issues
- Missing required fields in plugin.yml
- Main class not found or doesn’t extend PluginBase
- PHP syntax errors
- Type mismatches in strict-typed code
- Thread-unsafe calls in AsyncTask::onRun()
- Invalid event handler signatures
- Missing interface implementations
- Invalid API version format
Examples
Warning severity
Priority: 3 Warnings indicate problems that should be fixed but may not immediately crash your plugin. These issues can lead to bugs, unexpected behavior, or maintenance problems.Common warning issues
- Deprecated API usage
- Event handlers with incorrect parameter counts
- Plugin name contains spaces
- Outdated API versions
- Unused variables and parameters
- Missing return statements
- Visibility violations in lifecycle methods
- Unfetched data in AsyncTask
Examples
While warnings won’t crash your plugin immediately, they often indicate code that will break in future PocketMine-MP versions or cause subtle bugs.
Info severity
Priority: 2 Info-level issues are suggestions for improving code quality, maintainability, or following best practices. They’re not critical but can make your code better.Common info issues
- Non-semantic versioning in plugin.yml
- Plugin name with spaces (discouraged)
- MONITOR priority event handler usage
- Handling cancelled events (may be intentional)
- Suggestions for code improvements
Examples
Hint severity
Priority: 1 (Lowest) Hints are minor suggestions for style improvements, optimizations, or coding conventions. These are the lowest priority and often subjective.Common hint issues
- Code style suggestions
- Minor optimizations
- Alternative approaches
- Documentation suggestions
Examples
Hint-level issues are often safe to ignore if they don’t align with your coding style or project requirements.
Severity in reports
Severity levels are displayed differently in each report format:Markdown reports
JSON reports
HTML reports
HTML reports use color coding:- Red for errors
- Yellow for warnings
- Blue for info
- Gray for hints
Filtering by severity
You can exclude specific severity levels from your analysis:retina.yml
- Focusing on critical issues first
- Reducing noise in CI/CD pipelines
- Different strictness levels for different environments
Example: Production vs development
Severity assignment
Retina assigns severity levels based on the issue category and context:| Category | Typical Severity | Reasoning |
|---|---|---|
| syntax_error | Error | Prevents code execution |
| thread_safety | Error | Causes crashes |
| invalid_event_handler | Error | Handler won’t be called |
| deprecated_api | Warning | Works now, will break later |
| unused_variable | Warning | Indicates dead code |
| invalid_event_priority | Error | Invalid configuration |
| cancelled_event_access | Info | May be intentional |
| Plugin name with spaces | Info | Discouraged but functional |
- Severity enum: src/Issue/IssueSeverity.php:8
- Priority values used for sorting: Error=4, Warning=3, Info=2, Hint=1
Recommended workflow
- Fix all errors first - These will cause immediate problems
- Address warnings - These prevent future issues
- Review info suggestions - Improve code quality
- Consider hints - Optional improvements