Use an explicit UTC formatter with an English locale while preserving the
existing timestamp format, preventing timezone-only server comparison diffs.
Add an endpoint regression test that switches the JVM default time zone
back and forth and verifies stable UTC output and epoch milliseconds.
Assisted-By: GPT-6 Astra
Make WindTrackMasterData.windTrack transient and transmit each wind track's
fixes as individual top-level writeObject(...) calls terminated by a null
sentinel (mirroring the bug6227 GPS-fix streaming), resetting the
ObjectOutputStream handle table every FIXES_PER_HANDLE_TABLE_RESET fixes.
This restores reader/writer interleaving so the importer keeps draining the
HTTP socket during large Mongo inserts, avoiding the Jetty connector
idle-timeout EofException / Premature EOF on multi-day wind tracks.
The deduping against already-present fixes is preserved on the import side.
Assisted-By: Claude Opus 4.8
Merge the latest eclipse/main. The only content eclipse/main carried
past the branch point was the bug6318 WPub.dll JSON-action stopgap for
the ORC public-certificate adapter. bug6319 is the intended replacement
for that stopgap: it migrates the same adapter onto ORC's new key-based
JSON API at https://sas.orc.org/api/{key}/<endpoint> and restores the
pre-bug6318 semantics (country-less search, year search, real overview
counts and VPP year).
The two reworks touch the same files incompatibly, so all five ORC
adapter/test conflicts are resolved to the bug6319 version, discarding
the superseded bug6318 hunks:
ORCPublicCertificateDatabase.java
impl/ORCPublicCertificateDatabaseImpl.java
test .../orc/FailIfNoValidOrcCertificateRule.java
test .../orc/TestORCPerformanceCurve.java
test .../orc/TestORCPublicCertificateDatabase.java
MANIFEST.MF auto-merged identically on both sides (the x-friends
dedup). The resulting tree is byte-identical to the bug6319 tip.
Assisted-By: Claude (Opus 4.8)
Add an October 2026 Admin Console release-notes entry announcing the migration
of ORC certificate retrieval to the key-based sas.orc.org web API (the previous
public endpoints were decommissioned by ORC). Self-hosting administrators must
now configure the ORC_API_KEY environment variable for the server process; the
SAP-hosted landscape already has it provisioned. Links issue #6319.
Assisted-By: Claude Opus 4.8 (claude-opus-5-5)
Record in the adapter's class Javadoc that activecerts (and thus search())
only ever returns active certificates, that the sole wired route to an
inactive certificate is DownBoatRMS_byrefno by a known RefNo, and the
two-hop country-fleet → dxtName → DownBoatRMS path that would let one
discover inactive certificates by boat identity (not wired today; would
also need a dxtName-keyed handle representation).
Also fix a stale {@link #search(..., boolean)} reference to the current
6-arg signature.
Assisted-By: Claude Opus 4.8 (claude-opus-4-8)
The key-based sas.orc.org API routes all active-certificate search through the
activecerts endpoint, which returns active certificates only. The includeInvalid
flag on ORCPublicCertificateDatabase.search(...) could therefore never change the
result and was dead. Remove it from the interface and impl, the default
getCertificateHandle, the two fuzzy-search call sites, SailingServiceImpl, and all
ORC test call sites. The sole route to an inactive certificate in this adapter is to
download it by reference number via DownBoatRMS_byrefno (getCertificate /
getCertificateHandle); the search Javadoc now states this explicitly.
Also export ORC_API_KEY from java/target/env-default-rules.sh so the Java VM can read
it via System.getenv(...). configuration/secrets assigns it as a plain (non-exported)
shell variable that the java child process would not otherwise inherit; it is passed
as an environment variable rather than a -D system property so it is not exposed on
the process command line.
Assisted-By: Claude Opus 4.8 (claude-opus-5-5)
Add an entry under "Tuning the Eclipse Installation" explaining that
ORC_API_KEY must be defined as an Eclipse String Substitution variable and
referenced as an environment variable in the test launch configuration, but
only if one wants to run the ORC public-certificate tests
(TestORCPublicCertificateDatabase, TestORCPerformanceCurve) locally with
success. Without the key these tests fail on purpose (rather than being
skipped) so the misconfiguration is noticed; offline tests still run.
Also describe how to obtain a key: ask the team lead, or request your own via
ORC Sailor Services -> Developers page (request API access, then create keys
once granted), noting that a key is shown only once at creation.
Assisted-By: Claude (claude-4.8-opus)
Under the new DownBoatRMS_byrefno endpoint, searchForUpdate keys on the
reference number and returns the newest certificate for that RefNo. The
activecerts seed row's dxtDate can therefore be newer than the certificate
returned by searchForUpdate, so the previous invariant "an update is never
older than the original" no longer holds and made the test flaky across the
randomly shuffled seed from FailIfNoValidOrcCertificateRule.
Replace the issue-date ordering assertion with a reference-number round-trip,
which is the invariant the byrefno endpoint actually guarantees. The issuing
country assertion is kept.
Assisted-By: Claude (claude-4.8-opus)
Replace the decommissioned data.orc.org/public/WPub.dll XML endpoints with the
new key-based JSON API at https://sas.orc.org/api/{key}/<endpoint> (docs:
https://sas.orc.org/api-docs.php), restoring the pre-bug6318 semantics that the
bug6318 stopgap had regressed:
- country-less and year-based search via the 'activecerts' endpoint
(all criteria optional and AND-combined server-side; no criteria -> every
active certificate), removing the forced-country / current-year-only branches;
- real per-country/family overview counts and VPP year via the 'RMS' endpoint,
replacing the stubbed certCount=0 / vppYear=null;
- full-certificate download via 'DownBoatRMS_byrefno' (top-level rms[], consumed
by the unchanged ORCCertificatesJsonImporter);
- TestORCPerformanceCurve bulk online fetch via 'DownRMS'.
The API key is read from the ORC_API_KEY environment variable and placed into the
request path; it is never logged. When the key is absent the adapter throws, so
the live tests FAIL loudly rather than skip. The two pure-offline date-parse tests
run independently of the key. release.yml passes ORC_API_KEY to the test runtime,
gated so compile-only (skip_tests) runs never see the real secret.
Assisted-By: Claude Opus 4.8 (claude-opus-4-8)
Drop the hardcoded ORC bulk-download URL from TestORCPerformanceCurve.initialize()
and instead obtain the authenticated per-country bulk JSON stream from
ORCPublicCertificateDatabaseImpl.openBulkCertificatesJsonStream(CountryCode). All
endpoint knowledge (host, path, action, ext) now lives in the impl, the online fetch
gains the Authorization header it was previously missing, and no method has to be
added to the public ORCPublicCertificateDatabase interface. The .impl package is
reachable from the test because it is exported with an x-friends restriction naming
com.sap.sailing.domain.test; clean up the duplicated friend entry in the manifest.
Assisted-By: Claude Opus 4.8 (claude-opus-5-5)
The logger field became unused once the country-overview-based online fetch
was replaced with a fixed GER bulk fetch in setUp (its only use was the
"Trying to read country certificates for ..." info line). Remove the field
and the now-unused java.util.logging.Logger import so the workspace stays
warning-free.
Assisted-By: Claude Opus 4.8 (claude-opus-5-5)
The legacy data.orc.org WPub.dll XML entry points the adapter depended on
were decommissioned: search() POSTed action=ListCert and
getCountriesWithValidCertificates() GET /RMS, both parsed as XML. They now
302-redirect to HTML / return empty bodies, so parsing as XML tripped the
DOCTYPE / NPE path and failed every ORC test.
Rework the adapter onto the two surviving JSON actions:
- ?action=DownBoatRMS&RefNo=<ref>&ext=json (single certificate)
- ?action=DownRMS&CountryId=<IOC>&ext=json (per-country bulk)
The global DownRMS (no CountryId) still yields the Countries list used by
getCountriesWithValidCertificates().
ORCPublicCertificateDatabaseImpl:
- new httpGetJson() (HttpGet + lax redirects + Basic auth; inline
BOMInputStream charset detection; JSONParser), wrapping org.json.simple
ParseException in IOException so no org.json type leaks into signatures;
- parseHandleFromJson() mapping the rich rms-row schema (NatAuth->country,
BIN->fileId, GPH, RefNo, Family, Age_Year->yearBuilt, IssueDate) with
tolerant asString/asDouble/asInteger helpers and familyFromString();
- search(): RefNo-direct via DownBoatRMS, else per-country bulk via DownRMS
with client-side matchesClientFilters() (name/sail/boatclass/year); the
JSON actions return only valid certs, so includeInvalid is retained for
API compatibility but no longer branches;
- getCountriesWithValidCertificates() reads the top-level Countries array,
skips the ORC pseudo-entry; throws clause narrowed to IOException;
- searchForUpdate() now queries by RefNo (dxtName no longer exists);
- fuzzy search derives the issuing country from the sail-number prefix
(countryFromSailNumber) so bulk lookups have a CountryId;
- dead XML parseHandle(Node)/parseCountryOverview(Node) removed.
ORCPublicCertificateDatabase: narrow getCountriesWithValidCertificates()
throws to IOException; Javadoc updated to the JSON actions; https.
Tests: FailIfNoValidOrcCertificateRule probes a fixed strong country (GER)
instead of the now-unavailable cert-count ranking. TestORCPublicCertificate-
Database replaces the dead FRA00013881/SOULMATE fixture with a live
self-seeding pickSeedHandle(); all live tests gated by
@FailIfNoValidOrcCertificates. TestORCPerformanceCurve.setUp fetches the GER
bulk JSON directly. Full com.sap.sailing.domain.orc package: 28/28 green.
Assisted-By: Claude Opus 4.8 (claude-opus-5-5)
The with-java11-non-android-relevant profile was bounded by an upper JDK
version, so with Maven running on JDK 25 the routeconverterjava11extension
fragment was missing from the test runtime. On docker-* branches (tests
on JDK 8 with JavaSE-11.profile) routeconverter then loaded javax.xml.bind
from rt.jar via boot delegation, while Tycho 5's new test TCCL exposes
jaxb-impl's META-INF/services entry, so the bundled impl (wired to the
jaxb-api bundle) got picked, causing JAXB ClassCastExceptions and
IllegalAnnotationsExceptions in com.sap.sailing.server.trackfiles.test.
Assisted-By: Claude Opus 5.5
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The runWhenDoneLoading rewrite in 15dbbc03a1 (companion bug6241
listener-leak fix) made runWhenDoneLoading register a race-removal
listener on the race's regatta via TrackedRegatta.addRaceListener. When
a replica performs its initial load from a master
(RacingEventServiceImpl.initiallyFillFromInternal), it registers a
synchronous RaceAdditionListener on each deserialized regatta. Those
regattas already contain their races, so addRaceListener's catch-up loop
fires raceAdded for every existing race -- and it did so from INSIDE the
ConcurrentHashMap.computeIfAbsent mapping function, because the
SynchronousRunnableExecutor runs the dispatch inline. raceAdded then
called runWhenDoneLoading, which re-entered addRaceListener and nested a
second computeIfAbsent on the same raceListeners map while the outer one
still held the key's reservation node. ConcurrentHashMap forbids the
mapping function from modifying the map, so the nested update spun/blocked
forever on the reservation node -- a single-threaded self-deadlock, not a
lock-ordering deadlock.
This affected production: a replica would hang indefinitely during
initial load from a non-empty master (both automatic replica startup via
the replication Activator and operator-initiated replication). It also
wedged the CI build, which runs the replication initial-load tests;
TrackedRaceWithSensorFixStoreContentsReplicationTest hung until the 6h
GitHub Actions cap cancelled the job. The normal getOrCreateTrackedRegatta
path was unaffected because the listener there is registered on a
freshly-created empty regatta (zero-race catch-up, no re-entry).
Fix: TrackedRegattaImpl.addRaceListener now captures the catch-up work in
a holder inside the mapping function and runs it AFTER computeIfAbsent
returns, with the entry fully installed and no reservation node held. The
holder is populated only when a new entry was actually created, preserving
the duplicate-registration collapse, and the catch-up dispatch still runs
under the trackedRacesLock read lock, so ordering relative to enqueEvent
is unchanged. A nested addRaceListener for a different listener key now
proceeds normally.
TrackedRaceWithSensorFixStoreContentsReplicationTest now passes in ~7s.
Assisted-By: Claude (Anthropic claude-4.8-opus)
Tycho 4.0.x implicitly contributed the JUnit Platform "suite" bundles to the
tycho-surefire test runtime, so our target platform never had to provide
org.junit.platform.suite.api itself. Tycho 5.0.4 no longer injects them, which
broke test resolution for every *.test bundle with:
Cannot resolve project dependencies:
You requested to install 'java.package; org.junit.platform.suite.api
[1.0.0,2.0.0)' but it could not be found
The 2024-12 release repository we already reference for JUnit 5 (Platform
1.11.3 / Jupiter 5.11.3) also provides the split suite artifacts, so add them
from the same repository and include them as bundles:
junit-platform-suite-api / -commons / -engine (+ .source) 1.11.3
suite-engine is included as well, at effectively no cost, to also support
running JUnit Platform @Suite classes via the suite engine.
Assisted-By: Claude Opus 4.8
3.9.16 is the newest release on the Maven 3.9.x line (which Tycho 4.0.x
requires) and is the version the GitHub runner image shipped as default
before image 20261004.327.1 bumped the default to the Tycho-incompatible
3.10.0. Pinning the image's former default avoids a per-run download.
Assisted-By: Claude Opus 4.8
Tycho 4.0.x is end-of-life (4.0.13 was the final release); upstream
recommends migrating to the 5.x main line. Tycho 5.x requires Java 21+ as
its runtime VM, which release.yml already satisfies (Maven runs on JDK
25), and still targets the Maven 3.9.x line, so the existing Maven 3.9.11
pin remains valid.
Only java/pom.xml is bumped. The standalone java/com.amazon.aws.aws-java-api
module is deliberately left at Tycho 1.7.0: it builds its local p2 repo
under JDK 8, and Tycho 5.x cannot run on Java 8.
This is an initial probe to see how the release build reacts; serialization/
replication validation (see Bugzilla 3859 note in java/pom.xml) still pending.
Assisted-By: Claude Opus 4.8
The GitHub-hosted ubuntu runner image bumped its default Apache Maven
from 3.9.x to 3.10.0 (image ubuntu24/20261004.327). Tycho 4.0.x requires
the Maven 3.9.x line; under Maven 3.10.0 Tycho's Sisu/Guice component
wiring fails at extension bootstrap with "No implementation for
MavenTargetLocationFactory was bound" while provisioning
DefaultTargetPlatformFactory, breaking the build.
Pin Maven to 3.9.11 via setup-maven in every workflow that runs Maven
(release, build-aws-sdk-p2, build-sailing-base-p2, build-jetty-p2) so the
build no longer depends on whatever Maven the runner image ships. The
action is SHA-pinned consistently (stCarolas/setup-maven v5.1).
Assisted-By: Claude Opus 4.8
JDK 21 flagged source/target 8 as obsolete. The Gradle app build already
runs under JDK 17 (buildAndUpdateProduct.sh / release.yml), and AGP 8.7
permits Java 17, so bump sourceCompatibility/targetCompatibility and the
ext compat vars to 17. This covers the 4 mobile modules and the 8 java/
library subprojects compiled by Gradle; the separate Tycho/Maven OSGi
build is unaffected (its BREE pins it to Java 8 independently).
Assisted-By: Claude (claude-opus-5-5)
Fixes CodeQL py/bind-socket-all-network-interfaces by binding the
local debug HTTP printer to 127.0.0.1 instead of all interfaces
(host = ''). The script is a small local debugging utility, so
restricting it to loopback does not affect its intended use.
Assisted-By: Claude Opus 4.8
After the Android 16 / AGP 8 / JDK 21 upgrades, opening the QR code scanner
in the Buoy Pinger app crashed with NoClassDefFoundError for the internal
GMS classes zzdkv / zzbgl when constructing BarcodeDetector.Builder.
Root cause: play-services-maps:17.0.1 forced play-services-basement/base up to
17.0.0 in the Buoy Pinger graph, while play-services-vision stayed at 12.0.1.
Vision 12.0.1 references internal classes that existed in basement 12.x but
were removed in 17.0.0, so they fail to resolve at runtime. Race Manager was
unaffected only because it pulls no maps dependency, keeping its whole GMS
stack at 12.x.
Fix (preserving minSdk 16 for old tracking/pinging hardware):
- Bump play-services-vision 12.0.1 -> 19.0.0. Vision 19.0.0 depends on
basement/base 17.0.0 (the versions maps 17.0.1 already pulls) and keeps
minSdk 14; the BarcodeDetector API is unchanged, so no barcode code changes.
- Bump play-services-location 12.0.1 -> 21.0.1 so Race Manager's fused-location
calls do not hit the same basement mismatch once vision raises basement; it
resolves to basement 18.1.0 (minSdk 14), consistent across all three apps.
- Modernize WindFragment's deprecated LocationRequest API (create()/setPriority/
setInterval/setFastestInterval and LocationRequest.PRIORITY_HIGH_ACCURACY) to
LocationRequest.Builder with Priority.PRIORITY_HIGH_ACCURACY.
Verified: all three app modules (Buoy Pinger, Tracking, Race Manager) compile
cleanly against the bumped versions, with no location deprecation warnings.
Runtime QR scan not yet smoke-tested on a device.
Assisted-By: Claude Opus 4.8 (claude-opus-5-5)
Since August 31, 2026 Google Play rejects app updates not targeting API
level 36 ("Target SDK of artifact is too low: <versionCode>").
Build:
- AGP 8.7.3 -> 8.13.2 (8.7 supports at most API 35; 8.13 supports 36.1
and works with our Gradle 8.14.3 / JDK 21)
- compileSdk 33 -> 36, targetSdk 35 -> 36, buildTools 34.0.0 -> 36.0.0
- azure-pipelines/main.yml: androidVersion 35 -> 36
Apps (all via the shared library, so all apps get it):
- Predictive back: opt out with android:enableOnBackInvokedCallback="false"
so that the existing onBackPressed() overrides and KEYCODE_BACK handling
keep being invoked on Android 16.
- Large screens: temporarily opt out of ignored orientation/resizability
restrictions on sw600dp displays with
PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY (ignored from API 37 on).
- Edge-to-edge, enforced without opt-out for targetSdk 36: new
SystemBarInsetsHandler, registered by LoggableApplication on Android 15+
devices, pads each activity's content view by the system bar, display
cutout and (unless adjustPan/adjustNothing) keyboard insets so content
no longer hides behind the status and navigation/button bar, and fills
the status bar area with the theme's colorPrimaryDark as before.
Document the androidVersion / Play target API requirement in
building-and-deploying.md.
Assisted-By: Claude Opus 5.5
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
When a fresh instance starts with an empty security store (one that does
not replicate its security service from a master), initEmptyStore() creates
the default "admin" user. Until now this always used the well-known password
"admin", created the account without enforcing a strong password, and logged
the password in cleartext.
Operators can now set the SAILING_ADMIN_INITIAL_PASSWORD environment variable
to supply the initial admin password. When set to a non-blank value, that
value is used and a strong password is enforced; the password value is never
logged. When unset, the previous "admin" default is kept for backward
compatibility (test / docker-deploy / CI) but a security warning is logged
recommending the variable be set, and noting that future versions may require
it. The cleartext password is no longer logged in either case.
This is opt-in and non-breaking; forcing the variable is left to a later
change after a deprecation period.
Assisted-By: Claude (Opus)
OAuthRealm and SecurityServiceImpl logged OAuth credentials in cleartext:
the access token, its token value, secret, and raw provider response, as
well as the request token and verifier. These are sensitive values that
should never reach log files, where they widen the blast radius if logs
are leaked or aggregated.
Replace them with non-sensitive success/failure messages that identify
the provider only. The request-token/verifier lines are also dropped to
FINE since they carry no diagnostic value beyond the provider name.
Assisted-By: Claude (Opus)
with valid AWS credentials in the env vars (see awsmfa) this script
will use findSailingAnalyticsServers and show the process configurations
found on them under /home/sailing/servers/*
Central Signing failed with HTTP 406 ("The requested list doesn't exist in
the library files") after 9e17c0b453 switched files2sign.json to the AGP 8
default <module>-release-unsigned.apk names: Non-ABAP Assembly allow-lists
the APK file name together with group/artifact ID per MoMa assembly, and
the allow-listed names are <module>-unsigned.apk.
Restore the allow-listed names in files2sign.json and let the releaseBuild
lane rename the APKs reported by the gradle action from
*-release-unsigned.apk to *-unsigned.apk, failing the lane if none is
found. This replaces the applicationVariants outputFileName rename dropped
in the AGP 8 migration without relying on the deprecated Variant API that
AGP 9 removes. Update building-and-deploying.md accordingly.
Assisted-By: Claude Opus 5.5
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The AGP 8 migration (5a78d3e8e3) dropped the applicationVariants
outputFileName rename that stripped "-release" from the APK name, so the
build now produces <module>-release-unsigned.apk. The central signing stage
of the sap-mobile-pipeline template signs Binaries/Android/<file> literally
as listed in files2sign.json, which still named <module>-unsigned.apk and
failed with "File does not exist". Point files2sign.json at the AGP default
names instead of reintroducing the deprecated Variant API rename, which
AGP 9 removes. Document the naming requirement and update the JDK version
in building-and-deploying.md.
Assisted-By: Claude Opus 5.5
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Under AGP 8 the CI 'build' task runs lintDebug as fatal. After the JDK 21 /
Gradle 8.14.3 / AGP 8.7.3 migration this surfaced several blockers that the
old Fastlane assembleRelease path never ran lint against.
Google Play SDK Index (RiskyLibrary):
- play-services-maps 12.0.1 is flagged as outdated and blocks publishing.
Split the shared play_services version variable into per-artifact versions
(maps/location/vision) so modules can diverge, and bump maps to 17.0.1 (its
minSdk floor is still 14, so no app needs a higher minSdk).
- Move play-services out of the shared library: it now exposes vision only
(the shared QR/barcode scanner). maps goes to Buoy Pinger (the only app with
a real map UI); location goes to Race Manager (WindFragment); the dead
play-services-gcm declaration is dropped from the tracking app.
- Race Manager no longer depends on maps: AppPreferences stored a wind
position as com.google.android.gms.maps.model.LatLng purely as a
(double,double) holder. Replace it with the existing domain type
com.sap.sse.common.Position / com.sap.sse.common.impl.DegreePosition.
targetSdk 35 runtime-correctness (local lint checks, not Play Console gates):
- TrackingFragment: register the GPS-disabled receiver with
RECEIVER_NOT_EXPORTED on API 33+ (guarded native flag; androidx.core 1.0.0
lacks the ContextCompat overload), suppressing UnspecifiedRegisterReceiverFlag.
- TrackingService: scope the gpsDisabled broadcast to this app's package so it
reaches the now non-exported receiver (fixes UnsafeImplicitIntentLaunch).
- RaceStateService / RaceLogPollingService: guard setExact with
canScheduleExactAlarms() on API 31+, falling back to inexact set().
- RaceStateService: declare POST_NOTIFICATIONS and guard the notify() update
with a runtime permission check on API 33+.
MissingInflatedId false positives: the referenced ids live in qualified layout
variants (e.g. race_schedule_start_time_normal.xml) that lint cannot resolve
from R.layout.race_schedule_start_time; suppress MissingInflatedId on the three
affected onCreateView methods.
Verified: ./gradlew lintDebug assembleRelease (JDK 21) and the CI gate
./gradlew build (JDK 17) both BUILD SUCCESSFUL with 0 fatal lint errors; all
three apps' apk/.version artifacts regenerate.
Assisted-By: Claude Opus 4.8
CI dropped JDK 17 for JDK 21; Gradle 7.6 cannot run on JDK 21, so the
wrapper was bumped to 8.14.3 (700bbcb1d2). That alone is insufficient:
AGP 7.2.2 references IncrementalTaskInputs (removed in Gradle 8.0), so
assembleRelease failed. Gradle 8.x and AGP must move together.
Changes:
- Root build.gradle: AGP 7.2.2 -> 8.7.3; grgit 2.3.0 -> 5.3.0 (classpath
and plugins block); ext.buildTools 30.0.3 -> 34.0.0 (AGP 8.7 floor).
- gradle.properties: enable AndroidX via the Jetifier shim
(android.useAndroidX=true, android.enableJetifier=true) and set
android.nonTransitiveRClass=false to restore the merged R so appcompat
attrs (e.g. R.attr.colorAccent) resolve as before.
- All 4 mobile/ modules: package= in AndroidManifest.xml -> namespace in
build.gradle; packagingOptions -> packaging; re-enable BuildConfig
generation (buildFeatures { buildConfig true }), off by default in AGP 8.
- 3 app modules: port the removed applicationVariants APK-copy to the AGP 8
androidComponents Artifacts API (CopyApkToWww consumes SingleArtifact.APK
via BuiltArtifactsLoader), reproducing the <packageName>.apk and
<packageName>.version output in java/com.sap.sailing.www/apps/.
- Jetifier rewrites dependency bytecode but not our own sources, so migrate
all android.support.* imports/FQNs/XML tags to androidx.* across mobile/.
- AGP 8 makes R fields non-final; convert every switch(R.id...) to if/else
(18 files) since case labels require constant expressions.
assembleRelease is BUILD SUCCESSFUL under JDK 21 / Gradle 8.14.3 and
produces the same APK and .version artifacts as before. Remaining warnings
are Gradle-10 space-assignment deprecations only; we are intentionally on 8.x.
Assisted-By: Claude Opus 4.8 (claude-opus-5-5)
The CI JDK was upgraded from 17 to 21, but Gradle 7.6 only supports
running on JDK up to 19. Running it on JDK 21 made the Groovy script
compiler reject the JDK-21 (class file major version 65) settings.gradle
with 'Unsupported class file major version 65' / 'Could not open settings
generic class cache'. Gradle 8.5 is the first release to support JDK 21;
8.14.3 is the latest 8.x (supports JDK 21-24) and avoids the breaking
changes of the 9.x line. Verified locally: 'gradlew help' configures the
:mobile Android project BUILD SUCCESSFUL under JDK 21.
Assisted-By: Claude Opus 4.8
On ARCHIVE (replay-heavy) startup the restore counters could drift:
numberofracesrestoreddoneloading short and numberofracesstillloading
negative (observed -1). The negative count traced to a single race whose
stillLoading-- callback fired twice against one matching raceAdded +1.
Every restored race arms runWhenDoneLoading twice, from two independent
sites with two distinct runnables (restore path -> doneLoading++, and
RaceAdditionListener.raceAdded -> stillLoading--), each meant to fire
once. The old runWhenDoneLoading removed its listener inside
statusChanged with no one-shot guard. Because notifyListeners snapshots
the listener set under lock and then iterates the snapshot outside the
lock, a removeListener happening during dispatch does not shorten an
already-in-flight iteration. When a race crossed past-LOADING twice
back-to-back under concurrent status pushes (loader finish plus the
stopTracking teardown), a second dispatch snapshotted the listener array
before the first dispatch's removeListener landed, so the callback fired
on both transitions -> two decrements vs one increment -> net -1 (and a
symmetric +1 over-count on doneLoading).
Rewrite runWhenDoneLoading to mirror runWhenPastLoading: a settled
AtomicBoolean CAS makes firing strictly one-shot per registration no
matter how many times or along how many concurrent paths the transition
is delivered, plus a cooperating regatta raceRemoved listener that tears
down and settles-without-firing if the race is removed while still
PREPARED/LOADING/ERROR (closing the companion bug6241 listener-leak
class).
Add TrackedRaceRunWhenDoneLoadingTest as contract tests for the
single-fire / already-done / removed-before-done / fire-then-remove
behaviours. Note these do not reproduce the production concurrency
interleaving: setStatus dispatches statusChanged synchronously and
sequentially, so single-threaded JUnit cannot deterministically recreate
the snapshot/remove race; the fix rests on the settled CAS.
Assisted-By: Claude (Anthropic claude-4.8-opus)
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)
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 barrier-based synchronization introduced earlier let the second query's
re-entry into computeMaxSpeed(...) await the auto-reset CyclicBarrier a second
time. Only the three fix-adding threads plus the first query's stale
computation ever reach the barrier, so on the second generation the number of
arriving parties depended on how many times computeMaxSpeed(...) got re-entered
via cacheLookup(...)'s recursive getMaxSpeed(entryTo, to) stitching after the
cache was invalidated. That count varies with thread scheduling: locally it
happened to reach the barrier's party count and returned fast, while in CI it
did not, so await(20s) timed out and the write lock was reported held for more
than 10s, failing the run consistently.
Gate the barrier await with an AtomicBoolean so that exactly the first
computeMaxSpeed(...) invocation waits on the barrier. Every later invocation
(the second query and all its recursive sub-range computations) skips it,
removing the scheduling-dependent second-generation rendezvous entirely.
Assisted-By: Claude Opus 4.8 (claude-opus-4-8)
The test reproduced a MaxSpeedCache race by letting a stale
computeMaxSpeed(...) result get cached after invalidating GPS fixes had
been added. It relied on a fixed Thread.sleep(1000) inside computeMaxSpeed
to "hope" the three fix-adding threads had reached the point of contending
for the cache's write lock. Under CI load this timing assumption broke and
the test failed with a CyclicBarrier TimeoutException.
Replace the sleep with an explicit CyclicBarrier (fixThreadsReadyToContend,
parties=4): the first query's stale computation and all three fix-adding
threads rendezvous on it, so the stale result only completes once the
invalidations are guaranteed to be about to contend. Hoist the threads to
named locals and join all of them, establishing happens-before between the
invalidations and the second query before asserting the recomputed maximum
speed. This removes the timing dependency and makes the ordering
deterministic.
Assisted-By: Claude Opus 4.8 (claude-opus-5-5)
this may have dated back to very old Android versions <2.3
and is no longer needed; dropping it should raise chances a socket / TLS
connection can be re-used across multiple HTTPS requests, improving
performance specifically on links with high latency
those had accidentally gotten deleted by commit
31003728e9dd5915a4c1c3d4c79d2ee24cb34128, crossing a correponding change
in the original repo, followed by a somewhat careless copy/overwrite
from here.
Legacy documents in CONNECTIVITY_PARAMS_FOR_RACES_TO_BE_RESTORED stored the raw
paramURL including a random=<nonce> query parameter. Current keying (via
TracTracRaceTrackerImpl.getParamURLStrippedOfRandomParam) writes and deletes
using the paramURL stripped of that nonce, so the raw legacy copies can never be
matched by replaceOne/deleteOne. They linger indefinitely, inflate the restore
queue, and are re-attempted on every server start.
This mongosh migration auto-discovers every database in a replica set, skips
those without the collection, and for each nonce-bearing document either deletes
it (when a stripped twin already exists) or strips the random= parameter in
place (when it is the only copy). Dry-run by default; APPLY=1 executes and first
copies each affected document into a per-DB _NONCE_BACKUP collection for
rollback.
Assisted-By: Claude Opus 4.8 (claude-opus-5-5)
The local branch of setup-maptiles-instance.sh runs
./linux_host/deploy_linux_host.py, which requires the "uv" tool. When uv
is not installed locally, the deployment failed. Probe for uv before the
pushd/deploy step and, if it is missing, prompt the user (defaulting to
No) before installing it via the official astral.sh installer. After a
confirmed install, source ~/.local/bin/env so uv is on PATH in the
current shell, then re-verify and abort with a clear message if it is
still missing or the user declines.
Assisted-By: Claude (claude-4.8-opus)
createRegattaLeaderboard() returned as soon as the create dialog's OK was
pressed, without waiting for the newly created regatta leaderboard row to be
rendered into the leaderboards cell table. A subsequent getLeaderboardDetails()
call could then race the AJAX round-trip, find no matching row yet, and return
null, causing NullPointerExceptions downstream (e.g. in linkRace()).
Wait until the new row (named after the regatta, see RegattaDescriptor.toString())
has been rendered before returning, mirroring createFlexibleLeaderboard(). This
fixes the intermittent failures of TestColumnsInLeaderboard.testLeaderboardPanelRefresh
and TestSwitchingOffStartOfRaceInference; the other callers of
createRegattaLeaderboard() were verified to still pass.
Assisted-By: Claude Opus 4.8 (Claude Code)
Axel Uhl
