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

yevhenhnes · September 5, 2023, 2:05pm

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

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!

Colin · September 7, 2023, 5:25pm

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.

yevhenhnes · September 11, 2023, 7:52am

Hi,
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.

Colin · September 13, 2023, 1:30am

Thanks.

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.

yevhenhnes · September 13, 2023, 6:54am

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

meedel · February 7, 2024, 11:56am

We see the same messages in de Sonarqube project scanning.
Even with the same timestamp.

Error Details
Validation of project failed:
o Date of analysis cannot be older than the date of the last known analysis on this project. Value: “2024-02-03T22:33:56+0100”. Latest analysis: “2024-02-03T22:33:56+0100”. It’s only possible to rebuild the past in a chronological order

In the project background tasks overview I see that the Started and Finished times are the same. The Duration time says 64ms
I think the scanning is to fast!

meedel · April 10, 2024, 8:29am

Is there maybe a fix for? If the scan is done within 1 second, ( the above example has a duration time of 64ms ) the scan failes with the message: Date of analysis cannot be older than the date of the last known analysis on this project.
Now these projects all end in failure.

regards,
Bert

Colin · April 10, 2024, 1:19pm

Hey @meedel

You tagged onto an inactive thread, so your post got lost. You’re also missing some important information that’s expected when reporting issues, like what version of SonarQube you’re using.

Is this repeatable across projects? Meaning you have examples of projects where analyses that take longer than 1 second succeed, but shorter than 1 second fail? I would associate the error message you’re getting to anything related to task start/finish time (only submission).

The code regarding this message is here:

github.com

SonarSource/sonarqube/blob/master/server/sonar-ce-task-projectanalysis/src/main/java/org/sonar/ce/task/projectanalysis/step/ValidateProjectStep.java#L111


      
            if (!isValidProjectKey(baseProject.getKey())) {
              validationMessages.add(format("The project key ‘%s’ contains invalid characters. %s. You should update the project key with the expected format.", baseProject.getKey(),
                ALLOWED_CHARACTERS_MESSAGE));
            }
          }
          
          private void validateAnalysisDate(ComponentDto baseProject) {
            Optional<SnapshotDto> snapshotDto = dbClient.snapshotDao().selectLastAnalysisByRootComponentUuid(session, baseProject.uuid());
            long currentAnalysisDate = analysisMetadataHolder.getAnalysisDate();
            Long lastAnalysisDate = snapshotDto.map(SnapshotDto::getCreatedAt).orElse(null);
            if (lastAnalysisDate != null && currentAnalysisDate <= lastAnalysisDate) {
              validationMessages.add(format("Date of analysis cannot be older than the date of the last known analysis on this project. Value: \"%s\". " +
                  "Latest analysis: \"%s\". It's only possible to rebuild the past in a chronological order.",
                formatDateTime(new Date(currentAnalysisDate)), formatDateTime(new Date(lastAnalysisDate))));
            }
          }
          
          private Optional<ComponentDto> loadBaseComponent(String rawComponentKey) {
            // Load component from key to be able to detect issue (try to analyze a module, etc.)
            if (analysisMetadataHolder.isBranch()) {
              return componentDao.selectByKeyAndBranch(session, rawComponentKey, analysisMetadataHolder.getBranch().getName());

yevhenhnes · April 10, 2024, 1:28pm

Hey @Colin, thank you for your reply. We have already fixed the issue. It was 2 scans running at the same time. We have fixed it and the issue is gone.