"Measures" tab is not working after update to 10.7.0.96327

Updated today from 10.6.0.92116 to 10.7.0.96327.

Opening the “Measure” tab of a project is not working any longer:

image

access.log:
… “GET /api/alm_settings/get_binding?project=xxxxxx HTTP/1.1” 404 - “https://sonar.yyyyyy.com/component_measures?id=xxxxxx” …

browser debugger:
404 for component?additionalField=… “404 - File or directory not found.”

Any idea?

Hi,

Just to be sure, you have full permissions on the project?

Can you do a full browser refresh (Ctrl-R) and try again? I’m wondering if maybe some old, pre-upgrade JS is cached in your browser.

 
Ann

Tried incognito and also empty cache, still error is shown.

Hi,

With any other error, I’d send you to your server logs, but a 404… I’m not sure where to go from here, so I’ve flagged this for more expert eyes.

Are you seeing this in just one project? Multiple? All?

 
Thx,
Ann

Thanks for taking care.

I see it on all projects of the server, and as well on a second server with the same version.

1 Like

Same “Info” can be found in the build pipeline step for publish

Hi,

That’s a 403 & so theoretically unrelated, but I appreciate your making sure we have all the data.

 
:smiling_face:
Ann

Hello @jensheidrich_acn ,

Could you be more precise on exactly what endpoint on the browser is failing?

You have specified only URL query parameters.

Is it the same one as this one?

access.log:
… “GET /api/alm_settings/get_binding?project=xxxxxx HTTP/1.1” 404 - “yyyyyy.com

Regarding your 403 error, are you sure your token is up to date?

Best,
Jacek

I am in the Web Browser and clicking on the tab “Measures”.

https:///api/measures/component?additionalFields=period%2Cmetrics&component=xxxxxx…

For the build step: the token is valid, everything works and results are published, it was just another similar observation.

Hey @jensheidrich_acn ,

Could you try to execute the following curl commands to your SQ instance?

curl -XGET -H Authorization: Bearer <myToken> https://{your-sq-url}/api/measures/component?additionalFields=period%2Cmetrics&component=xxxxxx

curl -XGET -H Authorization: Bearer <myToken> https://{your-sq-url}/api/alm_settings/get_binding?project=xxxxxx

Where ‘xxxxxx’ is your project key, and share the results?

Hi Jacek,
I am using the same global token (of the administrator) as used at Azure DevOps

api/measures/component
result:

[1] 299523
{"errors":[{"msg":"The \u0027component\u0027 parameter is missing"}]}

api/alm_settings/get_binding
result:

{"errors":[{"msg":"Insufficient privileges"}]}

It seems like your first call failed with a different error than 404.

Could you wrap your URL in curl statement into quotes: " " like and try again:

curl -XGET -H Authorization: Bearer <myToken> "https://{your-sq-url}/api/measures/component?additionalFields=period,metrics&component=xxxxxx"

For the second statement, it seems like the token you are using does not have permission to execute that action. Can you verify if the following user has access to see this project in SQ?

Hi Jacek,
I am the super admin, and I am using the token of this local admin.

No differences with quotes or using a user token (of admin).

@jensheidrich_acn ,

The error below indicates that you have wrongly created a curl query; double-check if it is correct.

[1] 299523
{"errors":[{"msg":"The \u0027component\u0027 parameter is missing"}]}

Is your SonarQube instance configured behind a reverse proxy?

Logged in as “Administrator”

After reading the api documentation, adding the required parameter “metricKeys”:

So in general it would work with the correct parameters, but nevertheless the UI fails:

  • Checking URL when clicking on “Measures” tab inside the Project:

https://SONARQUBE-URL/api/measures/component?additionalFields=period%2Cmetrics&component=PROJECT-ID&metricKeys=accepted_issues%2Cnew_technical_debt%2Cblocker_violations%2Cbugs%2Cclasses%2Ccode_smells%2Ccognitive_complexity%2Ccomment_lines%2Ccomment_lines_density%2Cbranch_coverage%2Cnew_branch_coverage%2Cconditions_to_cover%2Cnew_conditions_to_cover%2Cconfirmed_issues%2Ccoverage%2Cnew_coverage%2Ccritical_violations%2Ccomplexity%2Cduplicated_blocks%2Cnew_duplicated_blocks%2Cduplicated_files%2Cduplicated_lines%2Cduplicated_lines_density%2Cnew_duplicated_lines_density%2Cnew_duplicated_lines%2Ceffort_to_reach_maintainability_rating_a%2Cfalse_positive_issues%2Cfiles%2Cfunctions%2Cgenerated_lines%2Cgenerated_ncloc%2Chigh_impact_accepted_issues%2Cinfo_violations%2Cviolations%2Cprioritized_rule_issues%2Cline_coverage%2Cnew_line_coverage%2Clines%2Cncloc%2Clines_to_cover%2Cnew_lines_to_cover%2Cmaintainability_issues%2Csqale_rating%2Cnew_maintainability_rating%2Cmajor_violations%2Cminor_violations%2Cnew_accepted_issues%2Cnew_blocker_violations%2Cnew_bugs%2Cnew_code_smells%2Cnew_critical_violations%2Cnew_info_violations%2Cnew_violations%2Cnew_lines%2Cnew_maintainability_issues%2Cnew_major_violations%2Cnew_minor_violations%2Cnew_reliability_issues%2Cnew_security_hotspots%2Cnew_security_issues%2Cnew_vulnerabilities%2Copen_issues%2Cprojects%2Calert_status%2Creleasability_rating%2Creliability_issues%2Creliability_rating%2Cnew_reliability_rating%2Creliability_remediation_effort%2Cnew_reliability_remediation_effort%2Creopened_issues%2Csecurity_hotspots%2Csecurity_hotspots_reviewed%2Cnew_security_hotspots_reviewed%2Csecurity_issues%2Csecurity_rating%2Cnew_security_rating%2Csecurity_remediation_effort%2Cnew_security_remediation_effort%2Csecurity_review_rating%2Cnew_security_review_rating%2Cskipped_tests%2Ceffort_to_reach_software_quality_maintainability_rating_a%2Csoftware_quality_maintainability_rating%2Cnew_software_quality_maintainability_rating%2Csoftware_quality_maintainability_remediation_effort%2Cnew_software_quality_maintainability_remediation_effort%2Csoftware_quality_reliability_rating%2Cnew_software_quality_reliability_rating%2Csoftware_quality_reliability_remediation_effort%2Cnew_software_quality_reliability_remediation_effort%2Csoftware_quality_security_rating%2Cnew_software_quality_security_rating%2Csoftware_quality_security_remediation_effort%2Cnew_software_quality_security_remediation_effort%2Csoftware_quality_maintainability_debt_ratio%2Cnew_software_quality_maintainability_debt_ratio%2Cstatements%2Csqale_index%2Csqale_debt_ratio%2Cnew_sqale_debt_ratio%2Cuncovered_conditions%2Cnew_uncovered_conditions%2Cuncovered_lines%2Cnew_uncovered_lines%2Ctest_execution_time%2Ctest_errors%2Ctest_failures%2Ctest_success_density%2Ctests%2Cvulnerabilities

sending this with curl and user token ends also in:
html: ... <title>404 - File or directory not found.</title> ...

The response you are getting doesn’t look like the one you would get from the SonarQube; it looks like another component in front of your instance. Could you confirm if your SonarQube instance is behind a reverse proxy? If yes, are there any rules applied to it which could intercept 404 errors?

As an additional check, could you execute the following curl and share the results (please replace only SONARQUBE-URL, TOKEN and PROJECT-ID)?

curl -i -XGET -H "Authorization: Bearer TOKEN" "https://SONARQUBE-URL/api/measures/component?component=PROJECT-ID&metricKeys=missing_metric"

On a healthy and reachable instance this is the response you should get:

curl -i -XGET -H "Authorization: Bearer TOKEN" "https://SONARQUBE-URL/api/measures/component?component=PROJECT-ID&metricKeys=missing_metric"

HTTP/2 404 
date: Fri, 22 Nov 2024 13:50:19 GMT
content-type: application/json
vary: accept-encoding
strict-transport-security: max-age=31536000; includeSubDomains
access-control-allow-origin: *
access-control-allow-credentials: true
access-control-allow-methods: GET, PUT, POST, DELETE, PATCH, OPTIONS
access-control-allow-headers: X-Forwarded-For
access-control-max-age: 1728000

{"errors":[{"msg":"The following metric keys are not found: missing_metric"}]}%  

Hi Jacek,
Yes, we have an IIS reverse proxy configured locally, but as simple as possible. Only one inbound rule configured as shown below.

But this was there before, and the SonarQube server (previously on version 10.6.0.92116) worked before the update to 10.7 perfectly, also the “Measures” tab.

We are having in total three independent SonarQube servers running, all are configured in the same way, all were running perfect, and all are now updated to 10.7.0.96327 and showing the same issue with the “Measures” tab.

Regarding the curl command, I am getting the following output:

Calling it with the IP it looks different (just for verification):

Thanks for your support so far.

Ok, the configuration looks really simple so I don’t think it is reverse proxy causing issues.

Can you execute the curl command with exactly the same parameters as the UI using the valid User Token and share results? It is very important that all parameters are exactly the same as the UI is passing. Without this information, it is hard to say what is wrong with your instance, as the response you are sharing is just generic 404.