Skip to content

BUG: Report a missing typed getter as an assumption - #585

Open
oleksandrlazarenko-pi wants to merge 1 commit into
mainfrom
bug/584-typed-getters-assumption
Open

BUG: Report a missing typed getter as an assumption#585
oleksandrlazarenko-pi wants to merge 1 commit into
mainfrom
bug/584-typed-getters-assumption

Conversation

@oleksandrlazarenko-pi

Copy link
Copy Markdown
Contributor

Closes #584

What this fixes

The Nightly Pipeline failed on nine consecutive nights, 2026-09-02 through
2026-09-10, on every platform/JDK job of every open nightly PR. One test failure
was responsible for all of them:

ValueHashTests.Values_Hash_TypedGetters:149 The properties IsVisible,
IsVisibleJavaScript, HasWebDriver, HasWebDriverJavaScript, IsHeadlessare missing
getters in the DeviceData class.

Why it happened

ValueTests.typedGetters called fail(...) when the data file exposed a property
with no strongly typed getter. The two inputs to that check do not publish in step:

  • the data file gained the five properties around 2026-09-01;
  • DeviceData/DeviceDataBase are generated by ci/generate-accessors.ps1
    tools/PropertyGenerator, which reads the live 51Degrees metadata service.

The metadata service did not publish them until 2026-09-10, so Nightly Data File Change logged "No property changes, so not creating a pull request" every night
from the 2nd to the 9th, and only opened #583 on the 10th. For eight days there was
no change to this repository that could have made the assertion pass.

The change

A missing typed getter is reported as a JUnit assumption failure, so the test is
recorded as skipped with the full diagnostic instead of breaking the build. This is
already the house idiom for conditions outside the repository's control
(MetaDataHashTests, EvidenceKeysTests, EngineTests), and MavenRunListener
surfaces it as Assumption Failed at WARN.

Still hard failures, unchanged:

  • a getter that returns null for an available property;
  • a getter that does not throw PropertyMissingException for an unavailable one;
  • no property having a typed getter at all — the accessors are then broken or
    absent rather than behind, which is this repository's defect.

The reporting is now shared by the on-premise and cloud copies of ValueTests, so
the two cannot drift on this point. The scanning loop above it is still duplicated.

Also fixes the missing space that produced IsHeadlessare missing getters, which ran
the last property name into the sentence in both copies.

Tests

New MissingGettersReportTest (6 tests) in device-detection.shared. Four of them
fail against the pre-fix behaviour and pass with the fix, covering both defects: the
hard failure, and the missing space.

mvn -pl device-detection.shared test — 9 tests, 0 failures.
mvn -pl device-detection.cloud test-compile — success.

Known limitation

Losing a single getter while the rest survive is no longer caught. Detecting that
needs a checked-in list of the getters expected to exist; it is called out in the
javadoc rather than left implicit.

Not fixed here

Nightly Publish's Test stage only exercises the examples against packaged
artifacts and never runs ValueHashTests, which is why main looked green and
packages kept publishing for eight days while the repository's own suite was
failing. That is worth a separate issue.

Values_Hash_TypedGetters called fail() when the data file exposed a
property with no strongly typed getter on DeviceData. That condition is
not under this repository's control. The accessors are generated from the
51Degrees metadata service, the properties come from the data file, and
the two do not publish in step, so the check can be unsatisfiable by any
change made here.

That is what happened on 2026-09-01, when the data file gained IsVisible,
IsVisibleJavaScript, HasWebDriver, HasWebDriverJavaScript and IsHeadless.
The metadata service did not follow until 2026-09-10, so Nightly Data File
Change reported "No property changes" for eight days and the whole nightly
matrix was red on every platform and JDK for nine consecutive nights.

A missing getter is now reported as a JUnit assumption failure, so the
test is recorded as skipped with the full diagnostic and the build stays
green. This is already the idiom used elsewhere in the repository for
conditions outside its control, and MavenRunListener surfaces it at WARN.
The serious cases still fail hard: a getter returning null for an
available property, one that does not throw PropertyMissingException for
an unavailable property, and the case where no property has a getter at
all, which means the accessors are broken rather than merely behind.

Also fixes the missing space that ran the last property name into the
sentence, reporting "IsHeadlessare missing getters".

See issue #584
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.

Nightly CI fails when the data file gains a property before its typed getter

1 participant