test(ofrep): drop the one omission that was never about OFREP

This suite's declarableExcept list is long, and every name in it is something this
provider genuinely cannot do -- no lifecycle to observe, no events, no connection
to lose, a backend that decides so the caller's default never leaves the process,
a deserialiser that keeps the numeric types strictly apart. @large-integers was
the odd one out: it said nothing about OFREP at all, only that
Client.getIntegerDetails is a 32-bit Integer. The TCK refuses it centrally now, so
it is gone from the list and from the paragraph that explained it.

That matters more here than in the flagd suite, because here it was one name among
nine and a reader had no way to tell which of the nine described the provider.
Now all of them do.

Measured on the pinned testbed image: 65 scenarios, 46 passed, 17 skipped, 2
failed -- a clean run, identical to the previous pass, since this changes the
reason for a skip rather than the count. The stream now carries four "provider
does not declare capability" reasons and one "the Java SDK cannot express
capability LARGE_INTEGERS", which is the distinction a reader of the report needs.

No KnownDeviation changes: the existing DISABLED_FLAGS entry is unaffected, and a
capability no Java provider can be asked was never a deviation to record.

Signed-off-by: Simon Schrottner <simon.schrottner@flagsmith.com>

Author: aepfli

providers/ofrep/src/test/java/dev/openfeature/contrib/providers/ofrep/e2e/OfrepTckTest.java

@@ -24,9 +24,9 @@
  * <p><strong>The testbed does not yet serve the whole canonical flag set.</strong> Three flags the
  * suite's assets added are absent from {@code flagd-testbed} v3.8.0: {@code large-integer-flag},
  * {@code huge-integer-flag} and {@code integral-float-flag}. Only the first is reached —
- * {@code huge-integer-flag} is asked for solely under {@code @large-integers}, which is not
- * applicable in Java, and {@code integral-float-flag} solely under {@code @numeric-coercion}, which
- * is withheld below — so exactly one untagged scenario, the 32-bit precision one, fails with
+ * {@code huge-integer-flag} is asked for solely under {@code @large-integers}, which no Java
+ * provider can be asked, and {@code integral-float-flag} solely under {@code @numeric-coercion},
+ * which is withheld below — so exactly one untagged scenario, the 32-bit precision one, fails with
  * {@code FLAG_NOT_FOUND} until open-feature/flagd-testbed#392 lands.
  *
  * <p>The three falsy flags used to fail the same way and no longer do. The testbed's
@@ -208,12 +208,14 @@ public FeatureProvider createUnavailableProvider() {
      * exact-instance check is what makes the {@code @object} mismatch matrix work, and the
      * structured happy path passes through {@code resolve(Object.class, ...)}, which every non-null
      * value satisfies, and is converted with {@code Value.objectToValue} (Resolver.java:125-136).
-     * And {@link Capability#LARGE_INTEGERS} is withheld, as every Java provider withholds it, for a
-     * reason that is not about OFREP at all: the tag asks for 2^53 − 1 and
-     * {@code Client.getIntegerDetails} is a 32-bit {@code Integer} with no room for it. The limit is
-     * the SDK's, it is recorded once in Appendix F rather than in each run, and the scenario is
-     * skipped for an undeclared capability like any other. It is named here for the same reason
-     * {@code REINITIALIZATION} is — {@link Capability#declarableExcept} would otherwise claim it.
+     * And {@link Capability#LARGE_INTEGERS} is no longer in the list below, which is the one
+     * omission here that says nothing about OFREP. The tag asks for 2^53 − 1 and
+     * {@code Client.getIntegerDetails} is a 32-bit {@code Integer} with no room for it, so the limit
+     * is the SDK's; the TCK refuses the capability outright now rather than asking every Java
+     * adoption to remember, and {@link Capability#declarableExcept} no longer offers it. Its
+     * scenario is still skipped, with a reason naming the accessor rather than this provider — which
+     * matters more here than elsewhere, because every other name in that list <em>is</em> something
+     * this provider genuinely cannot do, and a reader should not have to guess which is which.
      *
      * <p>{@link Capability#VARIANTS} and {@link Capability#TARGETING} are declared, and unlike the
      * withheld tags above both are confirmed by a run rather than read from the source. The OFREP
@@ -305,8 +307,7 @@ public Set<Capability> capabilities() {
                 Capability.CONFIGURATION_CHANGE,
                 Capability.DISABLED_FLAGS,
                 Capability.UNAVAILABLE_INIT,
-                Capability.NUMERIC_COERCION,
-                Capability.LARGE_INTEGERS);
+                Capability.NUMERIC_COERCION);
     }
 
     /**

providers/ofrep/src/test/resources/tck/docker-compose.yaml

@@ -8,8 +8,9 @@
 #
 # That flag set is not yet the whole canonical one: v3.8.0 has none of large-integer-flag,
 # huge-integer-flag or integral-float-flag. Only large-integer-flag is reached by scenarios that
-# run here -- the other two sit behind @large-integers and @numeric-coercion, neither of which
-# this provider declares -- and it is reached twice: the untagged precision scenario, which gets
+# run here -- the other two sit behind @numeric-coercion, which this provider withholds, and
+# @large-integers, which no Java provider can be asked because Client.getIntegerDetails is a
+# 32-bit Integer -- and it is reached twice: the untagged precision scenario, which gets
 # the code default instead of 2147483647, and the @variants row that asks for its "max-int32"
 # variant and is answered with none. Both fail until open-feature/flagd-testbed#392 lands. Bump
 # the tag then.