Date of analysis cannot be older than the date of the last known analysis on this project

SonarQube Developer Edition 9.9.1 LTS
Jenkins 2.414.1 LTS
SonarQube deployed inside Kubernetes with Docker image
Sonar-scanner: sonar-scanner-

Hi Community.
We have faced with the issue during SonarQube background task:

 {"task":{"id":"AYpXXXccsj","type":"REPORT","componentId":"AYpXXXccsc","componentKey":"ProjectName","componentName":"Project Name","componentQualifier":"TRK","status":"FAILED","submittedAt":"2023-08-31T17:34:20+0000","submitterLogin":"admin","startedAt":"2023-08-31T17:34:20+0000","executedAt":"2023-08-31T17:34:26+0000","executionTimeMs":6073,"errorMessage":"Validation of project failed:\n  o Date of analysis cannot be older than the date of the last known analysis on this project. Value: \"2023-08-31T17:32:08+0000\". Latest analysis: \"2023-08-31T17:32:24+0000\". It\u0027s only possible to rebuild the past in a chronological order.","hasScannerContext":true,"pullRequest":"1403","warningCount":0,"warnings":[]}}

Initially, we thought that the SonarQube scans ran in parallel and it could be the cause of the issue, but as you can see on the screenshot below - scans ran by order, one by one:

Next scans in this pull request was successful:

I saw the similar topics in SonarQube Commuity and the reason of the issue was parallel Sonar Scans execution, but we don’t run the scans in parallel in our CI.

Could you please help to understand the root of this SonarQube behaviour?

Many thanks for your help!

Hey there.

Are these analyses coming from multiple build servers? This can often be a symptom of clocks that have drifted from a single source of truth.

Thank you for your reply.
We are using one build server, as you can see on the screenshot above - all analytics run one by one, and there no any overlapping.
Clocks are synchronised as well. As I see, in the response from SonarQube - there are only timestamps from Sonar server and there are no timestamps from build server. I think there is another reason of the issue. Besides, next scan was successful without any changes in infrastructure configuration.


One alternative explanation could be that there was some delay during analysis or in uploading the report to the SonarQube server that caused a scan that started later to be successfully submitted first (if for example, two commits were close together).

If this only happened once, I suggest monitoring to see if it happens again. Otherwise, I think we’ll have trouble figuring out the root cause with just one data point.

We will monitor the code analytics to see if the issue will happen again.
Thank you for your help.