How to retrieve more than 10,000 results using api/issues/search

SonarQube Server / Community Build
,
1

How to retrieve more than 10,000 results using api/issues/search with filters?

SonarQube Server : Community 9.9

I’m calling the api/issues/search endpoint with several filters (componentKeys, severities, statuses, types, etc.) and paginating the results.
However, I get this error:

image
image1299×196 15.8 KB

Even with filters applied, the API stops at 10,000 results.

Is there any recommended way to retrieve all matching issues beyond the 10k limit

2

Warm welcome @pranav007

Have you taken a look at api/projects/export_findings endpoint? I suggest you give it a try and let us know if it fulfills your need.

By the way, just out of curiosity, what is the reason for using outdated and not supported anymore version of SonarQube Server?

3

this API is not supported for community version 9.9

4

Another idea I could think of is to partition your requests by leveraging createdAt and createdBefore and write a script that makes one query after another for each month or year.

5

Hi @pranav007,

Welcome to the community!

Only the latest version of SonarQube Community Build is considered active, so you’ll need to update and see if the situation is still replicable before we can help you.

Your update path is:

9.9 → 24.12 → 25.12

You may find these resources helpful:

If you have questions about upgrading, feel free to open a new thread for that here.

 
Ann

6

The 10K issue limit has been around forever, so I doubt an upgrade will fix it (someone correct me if I’m wrong). The usual answer (“use parameters to narrow your search”) is fine when you’re at your terminal trying different things, but for automated scripts you need a guaranteed workaround.

For the latter I had to go brute force: use the api/components/tree endpoint with qualifiers ‘DIR’ to get the entire list of directories in your project, then loop through this list one-by-one and fetch the issues from each directory (api/issues/search with param ‘directories’ or ‘componentKeys’) and then stitch them together. Slow, but it WORKS. If you have more than 10K issues among the files in a single parent directory, then you’ll need to do individual files (we’ve never had that happen, fortunately).

(Script writers be warned: there’s a major breaking change in 10.2 that’ll probably force you to rewrite all your scripts.)

7

Hi @MisterPi,

There’s actually an ‘all findings’ web service you can call in Enterprise Edition($$) and higher. I don’t remember what version it started in, but it’s been quite a while.

 
HTH,
Ann

8

I know that – I was giving my workaround for the benefit of OP, who’s on Community, or anyone else who finds this thread (which I ran across while searching for a related topic).

9

Actually it’s not necessary to do one at a time. You can pass multiple directories using the directories param of /api/issues/search. I was hitting URL limits trying to do too many at a time, but doing, say, 32 at a time avoided that problem while getting almost all the perf benefit of aggregating searches.

So the algorithm is basically:

  1. Get the list of directories
  2. Fetch issues from N directories at a time
  3. If any fetch in (2) gets more than 10K, go through those N directories 1 at a time
  4. If any fetch in (3) gets more than 10K, go through that directory file-by-file
10

24.12? 25.12? I thought the rule was you had to go “through” each LTA. The ones I see on the docs page are 2025.1, 2025.4, and 2026.1. Did the numbers change?

11

Hi @MisterPi,

That is the rule. Or, that was the rule until we started doing mid-year LTAs.

The reason you have to stop at intervening LTAs is that in the version after an LTA we drop the DB migrations up through the new/current LTA. So, E.G., 2026.1 doesn’t know how to get there from 9.9.

But we don’t do that migration dropping after a mid-year LTA, so you don’t have to hit them in a migration path.

I know it looks like we’re trying to make it confusing. It’s just… a happy accident? :upside_down_face:

 
Ann

12

OK, so sounds like 2025.4 can be skipped. But the remaining numbers are still off. Does 24.12 == 2025.1, and 25.12 == 2026.1?

13

Hi,

Approximately, yes. It was a deliberate choice to not line up the cutoffs between Community Build and Server. Another :upside_down_face:

 
Ann

14

Ah, now I get it. So this page wasn’t in your list to OP; is it still valid? Determining the update path | SonarQube Community Build | Sonar Documentation

15

Hi,

It is. TBH, my initial reply was a canned answer which was originally composed before that page was created. :smiley:

 
Ann