[beekld]

Summary

An FDv1 fallback directive used to be permanent. Once a synchronizer or initializer sent one, the data system never went back to its FDv2 synchronizers. With no FDv1 fallback synchronizer configured, the synchronizer loop exited, and the data system reported Interrupted for the life of the client.

A fallback now lasts for a default TTL of one hour, minus a random jitter of up to half of it, and then the data system returns to its FDv2 synchronizers:

• With an FDv1 fallback synchronizer, the data system runs it until the TTL elapses, then stops it and starts the first FDv2 synchronizer.
• Without one, the data system reports Interrupted with the error of the directive and runs no synchronizer until the TTL elapses.

A directive that brings no data no longer raises readiness. With no FDv1 fallback synchronizer, MakeClient now returns ErrInitializationTimeout after its full wait, instead of ErrInitializationFailed at once.

Every fallback uses the default TTL. Supporting a TTL carried by the directive itself would be a breaking change.

---

Note

Overview
FDv1 fallback directives are time-limited instead of permanent. When an initializer or synchronizer requests fallback, the data system applies a default TTL of one hour (with up to half-duration jitter via shared jittered()), tracks fdv1FallbackUntil on the synchronizer list, and returns to configured FDv2 synchronizers when it expires—via the backoff wait loop, the 10s condition ticker (syncFDv1FallbackEnded), or maybeEndFDv1Fallback().

With an FDv1 fallback synchronizer, only that slot runs until the TTL ends; without one, status stays Interrupted (with the directive error) and no FDv2 synchronizer runs until the TTL elapses—replacing the old excludeAll() path that stopped the loop for good.

Initialization / readiness shifts when fallback brings no data: the ready channel is not closed immediately, so MakeCustomClient can hit ErrInitializationTimeout rather than failing init at once. E2E tests now assert Interrupted instead of Off.

LDRelayApplySDKKey docs now state that an SDK key change does not end an active FDv1 fallback (only unparks backoff).

^{Reviewed by Cursor Bugbot for commit de5722e. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 8a0d727. Configure here.}