[
https://issues.apache.org/jira/browse/UNOMI-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18095517#comment-18095517
]
Serge Huber commented on UNOMI-927:
-----------------------------------
h2. Fix version change
Moved from *unomi-3.1.0* to *unomi-3.2.0*.
h2. Why not 3.1
Verified against current {{master}} (2026-07-11): the bug is *still present*.
There is no merged PR and no migration script for this ticket.
This is *not a 3.1 GA blocker* for typical deployments. Sessions must stay open
longer than ~24.86 days before {{duration}} wraps and becomes negative. Most
web sessions are far shorter.
A proper fix needs more than a one-line change: API type change, docs, tests,
and a data migration for clusters that already have negative values.
h2. Current code state (master)
* {{Session.duration}} is still {{int}}; {{setLastEventDate()}} still casts
with {{(int) (lastEventDate.getTime() - timeStamp.getTime())}}.
* ES and OpenSearch session mappings still declare {{duration}} as {{long}} —
mismatch with the Java model.
* {{manual/src/main/asciidoc/datamodel.adoc}} still documents duration as
Integer.
* No groovy/painless migration exists to recompute bad values.
* {{origin/unomi-3-dev}} has *no diff* on {{Session.java}} vs {{master}}.
h2. Suggested 3.2 scope
# Change {{Session.duration}} from {{int}} to {{long}}; remove the {{(int)}}
cast in {{setLastEventDate()}}.
# Update {{getDuration()}}, {{SessionAccessor}}, shell CRUD output, and any
callers/tests that assume {{int}}.
# Align {{datamodel.adoc}} (Long, milliseconds).
# Add a migration script: for sessions where {{duration < 0}} (or where
{{lastEventDate}} and {{timeStamp}} exist), set {{duration = lastEventDate -
timeStamp}}.
# Optional cleanup: i18n labels for session duration condition still say
"seconds" in {{messages_en.properties}} — confirm UI semantics vs runtime (ms).
h2. Impact if left open
Rules and segments that compare {{session.duration}} can match wrongly on very
long-lived sessions only. Clusters without multi-week sessions are unaffected.
----
Ticket remains valid for 3.2. Reporter's analysis and linked code paths are
still accurate.
> Long Sessions can have a negative duration
> ------------------------------------------
>
> Key: UNOMI-927
> URL: https://issues.apache.org/jira/browse/UNOMI-927
> Project: Apache Unomi
> Issue Type: Bug
> Components: unomi(-core)
> Affects Versions: unomi-3.0.0
> Reporter: Jerome Blanchard
> Priority: Major
> Fix For: unomi-3.2.0
>
>
> When a session duration exceed a certain amount of time (24,86 days) the
> duration can be negative !
> Duration of a session is computed by the difference between 2 timestamp which
> are long values.
> Whereas, in the documentation and in ES mapping config, a Session's duration
> is supposed to be a long:
> [https://github.com/apache/unomi/blob/15ae3eaca8c640a00df255bb0da781fa55f19fa8/manual/src/main/asciidoc/datamodel.adoc#L503]
> {code:java}
> duration | Integer | The duration of the session in milliseconds{code}
> Also in the session mapping config for ESS and OS :
> {code:java}
> "properties": {
> "duration": {
> "type": "long"
> },
> "lastEventDate": {
> "type": "date"
> }, {code}
> [https://github.com/apache/unomi/blob/15ae3eaca8c640a00df255bb0da781fa55f19fa8/persistence-elasticsearch/core/src/main/resources/META-INF/cxs/mappings/session.json#L21]
>
> [https://github.com/apache/unomi/blob/15ae3eaca8c640a00df255bb0da781fa55f19fa8/persistence-opensearch/core/src/main/resources/META-INF/cxs/mappings/session.json#L21]
> In Session.java, there is a (int) cast when setting LastEventDate()
> [https://github.com/apache/unomi/blob/15ae3eaca8c640a00df255bb0da781fa55f19fa8/api/src/main/java/org/apache/unomi/api/Session.java#L191]
> {code:java}
> (...)
> public void setLastEventDate(Date lastEventDate) {
> this.lastEventDate = lastEventDate;
> if (lastEventDate != null) {
> duration = (int) (lastEventDate.getTime() - timeStamp.getTime());
> }
> }
> /**
> * Retrieves the duration.
> *
> * @return the duration
> */
> public int getDuration() {
> return duration;
> }
> (...){code}
> It is also unclear why, in some translation (i18n) entries, it is mentioned
> some thresholds for session duration in seconds (even of those entries seems
> to not be used) :
> [https://github.com/apache/unomi/blob/15ae3eaca8c640a00df255bb0da781fa55f19fa8/plugins/baseplugin/src/main/resources/messages_en.properties#L80]
> All duration in persistence are supposed to be milliseconds.
> Fixing the issue also requires a database migration to restore negative
> values into a real long value.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
