test(flagd): run the provider conformance suite against both resolvers

[aepfli]

Stacked on #1606. Base is feat/provider-tck, so this diff shows only the new work. Review
#1606 first — it describes the suite, the adoption API and the capability vocabulary, and none of
that is repeated here.

Part of #1607 and open-feature/spec#417.

The flagd provider under the conformance suite, both resolvers, in libs/providers/flagd/src/tck/.

Two spec files, because jest-cucumber accumulates step definitions in module state and two
runContainerizedProviderTck calls in one file would make every step ambiguous.

The directory is a sibling of src/e2e/, not a subdirectory of it. The suite used to be excluded
from the e2e run by one Jest config remembering to ignore a subdirectory of another; that line is
deleted, because a file is in src/tck/ or it is not. The unit config gained /src/tck/ in
testPathIgnorePatterns, which was not optional — without it nx test providers-flagd would collect
these specs and start Docker in the unit run.

What it declares

Both resolvers declare the same twelve: @events, @lifecycle, @stale, @configuration-change,
@object, @unavailable, @variants, @targeting, @disabled-flags, @standard-reasons,
@string-typing and @fully-typed-values.

The last two hold in both resolvers — RPC reads the type off the evaluation response, in-process off
the synced definition via flagd-core, and both refuse the string accessor for a non-string flag. All
four scenarios were verified as passing by name, not inferred from totals.

@numeric-coercion is not withheld here — it is refused by the implementation for every
JavaScript provider. typeof 10 and typeof 0.5 are both 'number', so requesting float-flag as
an integer is indistinguishable from requesting it as a float and no provider in this language can
satisfy the scenario. Naming it fails at configuration time with that reason, and the scenario is
skipped with a message saying the SDK cannot ask the question — not that this provider declined.

The finding: no Go-style asymmetry here

Go's flagd RPC resolver never emits PROVIDER_STALE while its in-process resolver does
(go-sdk-contrib#939), so the Go adoption
withholds @stale for RPC. JavaScript has no such split, and the reason is structural rather than
lucky.

Neither resolver decides anything about staleness. Both report a lost connection through a
disconnectCallback — service/grpc/grpc-service.ts and service/in-process/grpc/grpc-fetch.ts —
and the provider owns the whole transition in one place, flagd-provider.ts: emit Stale, arm a
timer, escalate to Error when retryGracePeriod expires. Because the contract exists once, the two
resolvers cannot diverge. That is the shape Go needs, and it has been noted on go-sdk-contrib#939.

The backend stack

One Compose file serves both conformance suites in this repository, at
libs/shared/tck-backend/docker-compose.yaml: the unmodified flagd-testbed image, service
backend, publishing 8013, 8015, 8016 and 8080 with no host port bindings — the suite requires
dynamically mapped ports and discovers them after startup. Each suite asks the harness only for the
ports it needs, so the extra ones cost nothing.

It used to be one file per adoption. Four hand-maintained copies across the four languages had
drifted on the image tag: this repository was on v3.10.1 while Go, Java and Python sat on v3.8.0,
so suites whose results are only comparable if they asked the same backend were asking two.
Resolved by aligning the other three up to v3.10.1, the current release — this repository's tag
is unchanged and the tallies below still stand on the image they were measured against.

Moving the file out of the project root opened a cache hole, which is fixed here. Both tck
targets inherit inputs: ["default", ...], where nx's default is {projectRoot}/**/* — so a
Compose file outside the project would not have invalidated the cache, and changing the image tag
could have returned a cached green against the previous image without starting it. Both targets now
name {workspaceRoot}/libs/shared/tck-backend/**/* explicitly. The accepted cost: nx's project graph
cannot see a join() path as an edge, so nx affected will not select these targets — harmless only
because nothing runs nx affected --target=tck.

Running it, and the tally

npx nx tck providers-flagd

130 scenarios over the two resolvers: 116 pass, 10 skip, 4 fail. The four are the
large-integer-flag fixture gap that
flagd-testbed#392 fills — two per resolver,
the mandatory precision scenario and the max-int32 @variants row — not provider defects, and
neither gets a deviation entry.

A red run with many more than four is this repo's own flakiness rather than the provider or the
backend. Two causes, both local and both worth knowing: Jest does not exit after a containerised run
here, so an orphaned worker keeps its testbed stack alive — two such processes from "completed"
runs were found still holding stacks, 11 and 22 minutes old — and under that contention the
launchpad's POST /start answers before the flags are evaluable. A control run at the pre-move tip
failed 43 of 130 on the same machine, worse than anything after, which is how we know the move did not
cause it. ps aux | grep jest and kill them between runs.

One deliberate omission: no jest.retryTimes on these specs, though the neighbouring flagd e2e suites
use 3. A conformance result that only holds on the third attempt is not a conformance result, so
contention surfaces as a failure rather than being retried away.

Worth filing against the JS flagd provider

1. The offline/file mode has no staleness contract at all. service/in-process/file/file-fetch.ts
   never receives or calls disconnectCallback — its connect ignores the reconnect callback — so a
   provider using offlineFlagSourcePath emits neither PROVIDER_STALE nor a reconnect
   PROVIDER_READY. That may be intended for a file source, but it is undocumented and invisible.
2. Doc/code mismatch on retryGracePeriod: configuration.ts documents @default 5;
   constants.ts sets DEFAULT_RETRY_GRACE_PERIOD = 10. Small, but it is the knob deciding how long a
   provider stays STALE before claiming ERROR.

[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.}