NIFI-14254 Correcting sort order of provenance events in clustered en…

[pkelly-nifi]

…vironments by surfacing event time in millis to the front-end

Summary

NIFI-14254

Tracking

Please complete the following tracking steps prior to pull request creation.

Issue Tracking

• Apache NiFi Jira issue created

Pull Request Tracking

• Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
• Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000
• Pull request contains commits signed with a registered key indicating Verified status

Pull Request Formatting

• Pull Request based on current revision of the main branch
• Pull Request refers to a feature branch with one commit containing changes

Verification

Please indicate the verification steps performed prior to pull request creation.

Build

• Build completed using ./mvnw clean install -P contrib-check
  • JDK 21
  • JDK 25

Licensing

• New dependencies are compatible with the Apache License 2.0 according to the License Policy
• New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

• Documentation formatting appears as expected in rendered files

[exceptionfactory]

Thanks for working on this issue @pkelly-nifi.

Instead of passing down the Event Time in milliseconds, it seems worth considering parsing the timestamp on the frontend and then sorting that value. With a constrained number of rows, it doesn't seem like too much of an impact, although I would look for some additional perspective from other frontend-focus contributors.

[exceptionfactory]

Alternatively, as mentioned in the Jira issue description, it may be worth changing the string formatting to ISO8601, which would address several issues. That might need to be mentioned in a migration guide, but I think that may be a better solution.

[pkelly-nifi]

Sounds good, thank you for your feedback. I had considered simply changing the TimestampAdapter's formatter to be an ISO8601 string, but I saw it was used in several other DTOs and I didn't want to affect anything else. I agree that it is likely better to switch to an ISO timestamp, so I will do some testing.

[pkelly-nifi]

I switched to using an ISO timestamp and everything appears to be functional and working as expected. I'd appreciate any additional feedback.

[exceptionfactory]

Thanks for the adjustment @pkelly-nifi, however, changing the general TimestampAdapter impacts a number of additional components. To keep this narrowly scoped, I recommend a new Adapter named something like ISO8601DateAdapter, and then updating the ProvenanceEventDTO to use that new adapter. Also, following the ISO8601 standard, the format should be yyyy-MM-dd'T'HH:mm:ss.SSSX

[pkelly-nifi]

Thank you, @exceptionfactory. That makes complete sense to do it with a new adapter. I just commited those changes, but called it ISO8601TimestampAdapter and went with yyyy-MM-dd'T'HH:mm:ss.SSSXXX since that seems to be a little more common, but I'm happy to switch it to just a single X if you feel strongly about it.