UnsupportedOperationException: null

  • ALM used - GitHub
  • CI system used - Github Action
  • Scanner command used when applicable - GH action “sonarsource/sonarcloud-github-action@master” with basic configuration.
  • Languages of the repository - PHP, JS, SQL
  • Error observed:
    14:57:32.588 INFO: Importing /github/workspace/phpstan-report.json
    14:57:32.747 INFO: Sensor Import of PHPStan issues [php] (done) | time=159ms
    14:57:32.747 ERROR: An error occurred when reading report file ‘/github/workspace/phpstan-report.json’, no issue will be imported from this report.
    UnsupportedOperationException: null

About 2 weeks ago (to be precise on June 20th between 14:40-14:46 AMS) our CI configured Sonar scanner started skipping the generated phpstan report.
It happened between two runs in different branches. There were no changes in configuration, or apps updates, or libraries updates. Before that time everything was ok, after that time - we get the abovementioned error in any branches (old or new ones).
Debug mode doesn’t add more information.

How can we get more information about the error and how to fix it?

Hi @caveman

Welcome to the community, and thank you for your report!

Could you send us a phpstan-report.json file, please?
Let me open the private thread if you don’t like to share it publicly.

Best
Marcin Stachniuk

I am seeing the same. Have attached a phpstan report.
phpstan-report.json (21.8 KB)

Since I was just setting up PHPstan for the first time I decided to try Psalm instead. I’m seeing the exact same error with Psalm:

INFO: Importing /github/workspace/psalm-report.json
ERROR: An error occurred when reading report file ‘/github/workspace/psalm-report.json’, no issue will be imported from this report.

This makes me pretty confident that this is NOT a problem with the formatting of the files but something broken in the code that pulls in these reports, especially since these sensors share a base class.

Seems like logging a little bit more of that exception at the debug level would be super helpful. If you’re still working from the open source project, I think the place to add another log message would be at line 66 of the AbstractReportImporter: sonar-php/sonar-php-plugin/src/main/java/org/sonar/plugins/php/reports/AbstractReportImporter.java at master · SonarSource/sonar-php · GitHub

The current code logs the error message and the exception, but none of the details that you’d need to understand why that error was thrown. Maybe logging the stack trace at the debug level would make it easier to solve these issues.

@Marcin_Stachniuk any suggestions? It sounds like this has been broken for weeks, I’d really like to get this going. Is there a better channel for these kinds of support issues for paying customers? I know we are on a paid plan, I’m happy to go figure out what kind of support contract we might have if that will help.

1 Like

Hi all!

Welcome @Ian_Ragsdale to the community!

I quickly examined the issue, and it required deeper investigation. I created a ticket for it: [SONARPHP-1503] - Jira, which you can follow.

For now, I can only suggest you disable PHPstan report import or try to use the previous version of PHPstan.

Best
Marcin Stachniuk

Hey @Marcin_Stachniuk thank you for opening that ticket! I think it might be worth noting in the ticket that it is happening not with just PHPstan but with Psalm as well, so I think it is unlikely to have anything to do with the format of the PHPstan report or the version of PHPstan. I just note this because it may help your dev team track it down more quickly.

I also tried going back to some older versions of the scanner to see if it was maybe an issue with a newer version, but I’m seeing the same errors. So I’m thinking it might be something on the server side.

Hey @Marcin_Stachniuk and @Colin, I’d like to express my disappointment at being featured in the community roundup email I received today. Not because I don’t appreciate the visibility but because the summary in the roundup repeats the same misconception that exists in the issue that Marcin created, which leads me to believe that neither of you actually looked at the additional information I provided.

As I pointed out in the second message I posted 9 days ago, the issue appears to affect not just every PHPstan report I’ve been able to test but Psalm reports as well, which I’d bet money means it has nothing to do with the specifics of the PHPstan report format. Because of this, your team appears to be treating it as an issue that can be worked around on our end, rather than a case of this being completely broken.

I want to make that clear because it doesn’t appear that anyone has actually looked at it yet and I’d expect the priority to be a bit higher considering the additional information I’ve provided. If it is NOT totally broken and is in fact working for some people, I’d really appreciate if someone can let myself and the original reporter know an effective workaround, because I’d really like to start seeing some linting reports for this project.

My company is paying for this service, and while I haven’t checked to see if we have a support contract, I’d expect a tiny bit more responsiveness than this to a paying customer. Nine days is a long time for something to be completely broken with no sort of update as to when we might expect to see a resolution.