GET /api/v2/sbom returns inconsistent "total" after Deletion

[carlosthe19916]

Problem:

• The endpoint GET /api/v2/sbom returns the response:

{"items":[],"total":1}

Notice that the "items" fields is empty, while the "totals=1".

Steps to reproduce:

Assuming we always use limit=10 to paginate the response.

• Upload more than 11 SBOMs (In the UI it would be represented in multiple pages)
• List the SBOMs using sort=name so you know which elements are at the end (second page): offset=10&limit=10
• Delete an SBOM from the second page offset=10&limit=10
• Search for the deleted SBOM using q=name_of_deleted_sbom

The response will be:

{"items":[],"total":1}

After some seconds the response will become:

{"items":[],"total":0}

Screencast.From.2026-05-07.16-58-31.mp4

In the video above an SBOM was deleted between seconds 0 to 20 seconds which generated the response {"items":[],"total":1}. And then after waiting for some seconds, we can see that at 1minute 24 seconds the same query regenerated a different response {"items":[],"total":0}. So the initial response where total=1 is incorrect

Note:

Manually deleting and uploading multiple sboms (around 15 each time) ended up generating the response:

{"items":[....some values here],"total":20947}

the interesting part is that there was no way for me to upload 20947 files, those are too many.
However I cannot reproduce this part so we can ignore this, I am sharing this part just in case it helps in the diagnosis of the problem

[carlosthe19916]

Btw: the full http query used for generating the error visualized in the video above is /api/v2/sbom?total=true&limit=10&offset=0&sort=name%3Aasc&q=rhn_satellite

[ctron]

It's not a bug, it's a feature. The totals are cached now. Default TTL for the cache is 60s.