This message is to report an error that I have experienced about issue sandboxing. We have SonarQube Server Developer.
The problem we have experienced is that an issue of a rule of the original installation has landed in the sandbox status. Additionally, the issues that should have landed to sandbox were not detected and were set to the open status.
These are the facts that have ocurred in our instance:
On 1th November we installed sonarqube server 2025.5 and created a copy of the original sonar-way java/js profiles “xxxx-java-rules” and “xxxx-js-rules” and set them to default. From there, we run several analyses as expected.
On 12th February we updated to Sonarqube Server 2026.1, run analyses and then activated Issue Sandboxing, expecting it to work upon the update to 2026.2 (we missed sandboxing of the 2026.1, because we run analysis before configuring the feature).
On 28th April we updated to Sonarqube Server 2026.2 (the sandbox was active) and before any analysis was performed, we activated manually the new rules that come with the update (remember that our default profile is not sonarway but a copy). Then we run analyses and we experience what I mentioned: One issue sandbox that should not be there and others that were set as open.
Find the following screenshots
Problem 1: Issue sandbox not correct from a rule that was activated on 1th November and NOT modified ever in the quality profile.
Problem 2: On 27th April, the instance had 11.989 issues. With the update of java and js of 11/15 new rules, the next analysis increased to 12.043, but only 14 were due to new issues in new code. So the rest should have landed in sandbox
The docs are unfortunately terse on the actual mechanics of sandboxing, so I checked in with the developers, outlining your scenario. Here’s what they told me
Enabling a rule is a manual action, which means the intent is to start raising new issues. This is not the same as an automatic update that you’re not necessarily aware of. So for such scenarios, we assumed people expect the new issues not to be sandboxed
Why is it that you think the issue should not have been sandboxed? Looking at your first screenshot, it’s dated to 9y ago. Since it’s also in the sandbox, that tells me it was newly raised and backdated. (The third screenshot backs that up.) That means the rule got smarter as a result of the update and raised a new issue on old code. And this is exactly what sandboxing was intended for.
I’m confused about what changed on the 27th, but earlier you said the version update happened on the 28th. Sandboxing only kicks in on the first analysis after a version update.
Dear Ann, I do not expect it sandboxed because it is not a new rule. Do you mean that sandboxing also applies when scanner becomes smarter and detects a new issue of a rule that was already in the profile?
Yes, take a look at the screenshot. The update was on 28th, I updated manually the profiles on 28th and new backdated issues arose on 28th. I expected them to have the status of sandboxing. Is the problem that I updated manually the default (copy) profile with the new rules of the update? Should I change the copy profile to inherit from sonarway to be able to get this feature to work in future updates?
I have another instance in which an issue was arisen and sanboxed after updating manually the copy profile.
In fact, that’s the only time it applies. From the docs:
Yes, exactly. You’ve made a copy of the default profile to avoid exactly the same problem that sandboxing is intended to address: surprise issues after an update. It’s the fact that you had to manually move the rules into your profile that prevented sandboxing from kicking in. If your profile is a close copy of Sonar way, it’s probably time to consider just defaulting back to it or - as you suggested - inheriting from it. Then there’s no need to manually add new rules, and sandboxing kicks in as intended.
Regarding your new screenshots, I’m not sure what I’m supposed to take away from them.
