Skip to content

Merged latest eclipse/main updates to downstream - #103

Merged
axeluhl merged 4 commits into
SAP:mainfrom
eclipse-sailing-analytics-bot:main
Oct 1, 2026
Merged

axeluhl merged 4 commits into
SAP:mainfrom
eclipse-sailing-analytics-bot:main

Conversation

@eclipse-sailing-analytics-bot

Copy link
Copy Markdown

Automated merge of upstream eclipse/main (and re-sync of downstream) into SAP/sailing-analytics:main.

Incoming commits (4)

  • release notes for MPC candidate time comparison fix (f5aea10)
  • bug6279: prove candidate time comparator overflow with a regression test (9de68eb)
  • properly compare candidate time points in mark passing calculator; (770bad9)

the old code subtracted the millisecond representation of the time
points from one another and cast the result to an int which may have
silently led to an overflow in case the difference between the time
points was greater than 49 days. For races with open-ended tracking time
ranges and sporadic fixes along that full time range may have caused
problems here.
The StartAndEndAwareTimeBasedCandidateComparator compared candidate time
points with (int) (o1.getTimePoint().asMillis() - o2.getTimePoint().asMillis()).
Epoch milliseconds are ~1.7e12, so for candidates more than Integer.MAX_VALUE
ms (~24.8 days) apart the 64-bit difference is truncated to 32 bits and its
sign can flip, turning the comparator into a non-total order. On the "my"
server this pinned all background-executor threads in TreeSet/NavigableSet
navigation and starved the maneuver-calculation queue (live candidate set
span was ~355.9 days, 14.3x the int limit).

CandidateComparatorOverflowTest reproduces the mechanism in isolation against
plain long epoch millis, independent of any domain type:
- truncatingCastReportsACyclicOrder: a single >2^31 ms step overflows and
  flips the sign, producing the cycle T_LOW > T_MID > T_HIGH > T_LOW.
- treeSetNavigationIsConsistentOnlyWithFixedComparator: the broken order makes
  TreeSet first()/last() disagree with the true chronological extremes.
- convergenceLoopTerminatesOnlyWithFixedComparator: an updateCandidates-shaped
  loop over a realistically sized multi-cluster set never drains under the
  buggy comparator (hits a 1,000,000-iteration cap) but drains in ~50 passes
  with Long.compare.

Assisted-By: Claude Opus 4.8 (Claude Code)

@axeluhl axeluhl left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@axeluhl
axeluhl merged commit 8b079ac into SAP:main Oct 1, 2026
12 of 14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants