Issue with Rule Comparison in MQR Mode – Severity Mismatch

  • 2025.4.1, in zip. Also in earlier versions

Hi there,

We’ve been administering this instance for quite some time. Originally, it operated in Standard mode, but it was later upgraded to MQR mode.

As a best practice, we usually create a copy of the Sonar Way quality profile, set it as the default, and use that copy to protect against unexpected changes during upgrades. When rule updates are needed, we typically use the profile comparator to review and decide whether to upgrade, activate, or deactivate specific rules.

However, we’ve encountered an issue with some profiles containing modified rules. Specifically, even after setting the recommended severity, the rule still appears in the list of rules to be modified.

Activating or deactivating the rule doesn’t resolve the discrepancy.

To investigate further, I retrieved the comparison data using the Web API, and here’s an example of what we found:

[*] Modificar:
[-] Web:S6848 - Non-interactive DOM elements should not have an interactive handler 

left: {'severity': 'MINOR', 'impacts': [], 'params': {}}
{
    "severity": "MINOR",
    "impacts": [],
    "params": {}
}

right: {'severity': 'MAJOR', 'impacts': [], 'params': {}}
{
    "severity": "MAJOR",
    "impacts": [],
    "params": {}
}

The comparator indicates a severity mismatch. However, in MQR mode, rule severity is no longer the key property; we now rely on impacts. And as far as we understand, severity cannot be changed in MQR if it was already customized before switching from Standard mode.

Recreating the profile from scratch isn’t an option, since the customer depends on the changelog to track rule modifications.

Switching back to Standard mode just to update the severity — and then returning to MQR — feels risky, as we’re unsure of the side effects.

What would you recommend in this case? Is there a supported way to resolve this kind of mismatch in MQR mode without losing changelog history or breaking the profile?

Regards,

Hi,

This was supposed to be fixed in 2025.4 (see SONAR-25204). You’re 100% sure it’s still appearing on your side after upgrading to 2025.4? Can it be your browser’s cache (this is a UI bug)? If it’s still present, we need to investigate further and why the fix isn’t working for everyone.

If a browser’s cache clear doesn’t solve the problem, in the meantime you can safely switch between Standard and MQR modes, and adjust the Standard severities to make the rows disappear. The switch is only about UI presentation and it doesn’t have an impact on how projects are analyzed or metrics are computed (on the backend, we always fully compute both modes, at all times; this is what allows you to seamless switch from one more to the other without needing to re-analyze all your projects). As long as you don’t change your Quality Gates in the short time you’re back in Standard mode, you’re safe.

1 Like

Hi, Wouter

This was, indeed, my bad. This customer is still in 3.1.

We postponed upgrading them to allow the 4.x release to be fine-tuned, but I made an error with my instance’s version.

In the meanwhile… could we highlight on the community topic rosen to issues to be resolved? It would help massively to us to locate issues reported earlier. (I haven’t seen this one reported, but I think is a common mistake)

Thank you!

1 Like

Wouter,

A colleague of mine had reported me this is also affecting 2025.1.3 (LTA):

Are there any plans to backport this fix into an hypothetical 2025.1.4?

Regards

This was initially reported internally :slight_smile: . I’m not aware of any community topic that mentions this.

Unfortunately, no :person_shrugging: . We don’t backport such small issues to the LTA. But it will be part of the next LTA in January.

1 Like

Thank you, Wouter!!

I have upgraded this instance to 4.2 and can confirm issue is fixed.

Thought LTA should receive all bugfixes available, but no upgrades. Isn’t that the point of the LTA?

Only security fixes and critical bugs (as in, which completely break a critical workflow). In this case, the feature is confusing but it’s not preventing anyone from doing their intended task. Hence, it is not considered critical enough to be backported to an LTA :man_shrugging: .

1 Like

Fair enough!

Thank you so much for your time and effort!

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.