Skip to content

feat: add override source configuration API and FDv2 wiring#409

Draft
kinyoklion wants to merge 2 commits into
rlamb/sdk-2655/internal-overridesfrom
rlamb/sdk-2655/override-source-api
Draft

feat: add override source configuration API and FDv2 wiring#409
kinyoklion wants to merge 2 commits into
rlamb/sdk-2655/internal-overridesfrom
rlamb/sdk-2655/override-source-api

Conversation

@kinyoklion

Copy link
Copy Markdown
Member

Connects the override layer to the outside world:

  • New public seam in subsystems: OverrideSource (implemented by sources; Start(sink)/Close) and OverrideSink (implemented by the SDK; SetOverrides takes a full replacement snapshot of flag/segment collections and the SDK applies the override marker itself). Both are new interfaces — nothing is added to any existing exported interface.
  • Configuration: a new OverrideSource field on subsystems.DataSystemConfiguration and an Overrides(...) builder method on ldcomponents.DataSystemConfigurationBuilder, so the eventual usage is ldcomponents.DataSystem().Default().Overrides(...). A single source, not a list: combining multiple documents (and the duplicate-key policy that implies) is the source's job, per the spec's multi-file semantics.
  • FDv2 owns the lifecycle: when a source is configured, it builds the layer and overlay, returns the overlay from Store() (all three client read paths — evaluation, prerequisites/segments, all-flags — go through that one accessor), starts the source synchronously before the run loop so a synchronously-loading source has its overrides in place before the client evaluates anything, and closes it first on Stop(). With no source configured, Store() returns the raw store and nothing about the system changes. The relay data destination and persistence keep seeing the raw store, and data availability is untouched by overrides. Overrides are inert in offline/disabled mode.
  • The internal dataSystem interface gains HasFlagOverride/HasOverrides probes (constant false for FDv1) — these are what the not-initialized short-circuit will consult in the next PR; nothing calls them yet.
  • internal/sharedtest gains a programmatic TestOverrideSource, which is both the test vehicle here and the reference implementation of the seam.

FDv1 behavior is unchanged; overrides are structurally FDv2-only since the configuration hangs off Config.DataSystem.

Based on #408 (the override layer this wires up).

SDK-2655

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.

1 participant