[aepfli]

Runs the OpenFeature Provider Conformance Suite against the GO Feature Flag provider, in both evaluation types. Builds on #1945 (merged), the root tck profile. Third backend after flagd (#1847) and Flagsmith (#1849). Go companion: go-sdk-contrib#1053, same testbed.

Result (64a35c59, per-mode declarations)

	passed	failed	skipped	of
in-process	64	0	1	65
remote	51	5	9	65

The remote failures are the 5 @disabled-flags scenarios, all recorded against #1850. The first run with everything declared had remote at 53 / 11 / 1.

The in-process skip, and one of the remote ones, is @large-integers, which the TCK refuses for Java: the integer accessor is 32-bit.

What it is

• tck/AbstractGoFeatureFlagTest holds the shared configuration. tck/InProcessTest and tck/RemoteTest set the evaluation type and their own declarations:
  • in-process pulls the configuration from the relay proxy and evaluates it in the WASM build of the GO Feature Flag engine. Polling is lowered from 2 min to 500 ms.
  • remote is OfrepProvider underneath.
• src/test/resources/tck/docker-compose.yaml pins aepfli/goff-tck-testbed 0.1.0: the unmodified relay proxy, plus a launchpad implementing the control API. The launchpad writes the flag file and forces POST /admin/v1/retriever/refresh. The rule is the same as for Flagsmith: fake the config source, never the evaluation.
• pom.xml adds the tck test dependency. No Jackson pin is needed, unlike Flagsmith.

What it declares

In-process: everything declarable, all of it passing. That includes @numeric-coercion, against my prediction. The GO Feature Flag engine narrows any float to int on an integer call, but the Java provider type-checks what the WASM returns, so float-flag read as an integer reports TYPE_MISMATCH. Whether the Go provider (native module, no such check) agrees is the next comparison.

Remote follows the OFREP adoption, because it is the same client:

• Withheld, because this mode does not attempt them (whether it should is asked in [go-feature-flag] Should remote evaluation emit events and fail init on an unreachable relay proxy? #1948):
  • @stale and @configuration-change: nothing polls.
  • @unavailable: init never contacts the backend, so a dead port reaches READY.
  • @numeric-coercion: OFREP is untyped and the client does an exact-instance check, so integer-flag read as a float returns the default. Strict typing is a legitimate choice, so no deviation is recorded.
• @disabled-flags is declared and failing, tracked as [OFREP] Should the provider handle codeDefaultFlag responses? Disabled flags surface FLAG_NOT_FOUND #1850. The relay proxy answers a disabled flag with DISABLED and no value (codeDefaultFlag), and the OFREP client reports FLAG_NOT_FOUND. All 5 such scenarios fail on the code or reason, never on the value. The in-process mode of the same provider gets it right.

So the Provider TCK job stays red on those 5 known failures (tck.testFailureIgnore is false, as in #1847).

Running it

mvn -Ptck -pl providers/go-feature-flag -am test

🤖 Generated with Claude Code

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}