fix: use millisecond precision for dataEntry metadata ETag

[stian-sandvold]

What

The GET /api/dataEntry/metadata ETag is built from the latest lastUpdated timestamp across the relevant metadata types, hashed together with the user UID. That timestamp was formatted with DateUtils.toLongDate, which truncates to whole seconds. This bumps it to DateUtils.toLongDateWithMillis so sub-second changes are reflected in the ETag.

Why

With second-level precision, two distinct metadata states that happen within the same wall-clock second produce the same ETag. Consequences:

• Correctness: a client that fetched the metadata and then sees it change within the same second can be served a stale 304 Not Modified and miss the update until the next change.
• CI flakiness: DataSetMetadataTest.dataSetMetadataEtagFunctionalityTest creates a dataset and asserts the ETag changed (line 103). When the create lands in the same second as the preceding read, the ETags collide and the assertion fails. This has been intermittently failing the Run api tests job on master (the same test/assertion across multiple unrelated commits, ~25-30% of runs).

Millisecond precision makes same-instant collisions astronomically unlikely and fixes both issues. The MD5 hash length is unchanged, so the existing 34-character ETag assertions still hold.

Testing

• mvn -pl dhis-web-api spotless:check passes.
• The change is a one-line precision bump to the existing ETag input; dataSetMetadataEtagFunctionalityTest continues to cover the behaviour.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 56.96%. Comparing base (17f8133) to head (6970795).
⚠️ Report is 11 commits behind head on master.

❗ There is a different number of reports uploaded between BASE (17f8133) and HEAD (6970795). Click for more details.

HEAD has 1 upload less than BASE

Flag	BASE (17f8133)	HEAD (6970795)
unit	1	0

Additional details and impacted files

@@              Coverage Diff              @@
##             master   #24046       +/-   ##
=============================================
- Coverage     69.04%   56.96%   -12.09%     
+ Complexity      709      555      -154     
=============================================
  Files          3684     3684               
  Lines        141646   141620       -26     
  Branches      16453    16452        -1     
=============================================
- Hits          97797    80668    -17129     
- Misses        36243    53524    +17281     
+ Partials       7606     7428      -178     

Flag	Coverage Δ
integration	49.65% <100.00%> (+<0.01%)	⬆️
integration-h2	29.64% <0.00%> (-0.01%)	⬇️
unit	?

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
.../java/org/hisp/dhis/webapi/utils/ContextUtils.java	57.77% <100.00%> (ø)

... and 986 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 05b1dbc...6970795. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jbee]

I feel this recognizes the issue and then applies the wrong fix. The cause was to not use the timestamp as it nature of being a number but to use some formatting which just makes is unnecessary complicated and error prone. So I suggest the fix is to use timestamp as numbers, not format the number differently.

[stian-sandvold]

Do you mean @jbee to not use the md5 hash to generate the etag string? Because the main change with the timestamp here is not that we format it differently, but add more granular information by adding milisecs in addition to seconds, since seconds where to rough to pass the test.

In theory, this fix leaves the test still flaky, but to be able to trigger that failure we would need a significantly faster execution time of the tested code

[jbee]

@stian-sandvold I am saying this

String value =
        String.format("%s-%s", DateUtils.toLongDateWithMillis(lastModified), user.getUid());

could and should just be

String value = String.format("%d-%s", lastModified, user.getUid());

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud