Question
Analysis rejected because its date is older than the last known analysis: which layer controls the timestamp?
Ash Nova
0 reputation · 18 Dec 2020, 03:01 UTC
137.8K views1
Loading…
0 reputation · 18 Dec 2020, 03:01 UTC
Our SonarQube server intermittently refuses to integrate a scanner report with a Compute Engine error indicating the analysis date is older than the date of the last known analysis for the project (exact wording unverified for our version). The scanner succeeds locally; the failure appears in the project's Background Tasks page during report processing.
From what I understand, the analysis timestamp is generated on the scanner machine, while the comparison against the project's latest snapshot happens server-side, dates are stored using the server/JVM time context, and the web UI converts them to each browser's local zone. Our scanner fleet runs on hosts in different regional time zones, and there appears to be no dedicated SonarQube timezone property — only the JVM default (user.timezone) and database server settings.
Target version: a current LTS with an external PostgreSQL database; exact behavior may differ from the embedded evaluation database.
Questions:
30275 reputation · 18 Dec 2020, 05:30 UTC
When a scanner submits an analysis, it includes a analysisDate field in the XML/JSON payload. The SonarQube server receives that value and stores it in the project_version table (or the equivalent table in the PostgreSQL schema). The server then compares this stored value against the analysisDate of the most recent snapshot for the project. The comparison is purely database‑side: the server does not substitute its own timestamp unless the scanner omits the field.
sonarqubeanalysisDate can be older than the last snapshot, triggering the “analysis date is older” error.analysisDate column is defined without a default; the scanner must provide it. The server does not overwrite it.date
# or, if using Docker
docker exec -it scanner-host date
ssh user@sonarqube-host "date"
psql -U sonarqube -d sonarqube -c "SELECT project_key, analysis_date FROM project_version ORDER BY analysis_date DESC LIMIT 5;"
grep -R "sonar.analysis.*" /path/to/sonar-scanner/conf/sonar-scanner.properties
systemctl status ntp
# or for chrony
systemctl status chronyd
analysisDate supplied by the scanner and stored in the database. Clock skew can indeed trigger the rejection if the scanner’s clock is behind the server’s clock.-Duser.timezone=UTC) on both scanner and server machines is the safest approach. If all clocks are NTP‑synchronized, using local time zones is technically safe, but any drift will affect the comparison.To narrow down whether the issue is scanner‑side or server‑side, please provide the exact analysisDate value that the scanner sends for a failing job and the timestamp of the last successful analysis in the database.
Use comments to ask for clarification. Post a solution as an answer.
30,275 reputation · 18 Dec 2020, 04:35 UTC
One point worth separating from the existing answer: System.currentTimeMillis() returns an absolute UTC instant, so the scanner's user.timezone does not shift the analysisDate it submits — a scanner in America/New_York and one in UTC send the same instant if their clocks agree. The zone only affects how dates render in logs and the web UI. That means standardizing every host on UTC is operationally nice but not the fix; the actual trigger is clock skew — a scanner whose clock lags behind the timestamp of the project's last stored snapshot.
Rather than only checking date on each host, compare offsets directly, e.g. chronyc tracking or ntpq -p, and look at the scanner log line Analysis date: ... versus the newest analysis_date row in the database. Intermittent failures across a regional fleet often point to one host with a drifting or unsynchronized clock.
Assumes a current LTS (10.x); worth verifying against your exact version's release notes.