Problem
OFREP static-context providers currently use an in-memory bulk evaluation cache. This works while the OFREP service is reachable, but the cache is lost across application restarts and cannot be reused during offline startup or temporary network loss.
This is a poor fit for web and mobile environments, where intermittent connectivity and app restarts are common. A client may have a previously successful bulk evaluation, but without local persistence it falls back to errors or code defaults instead of continuing from the last known state.
Proposed Solution
Recommend that static-context providers persist their last successful bulk evaluation in local persistent storage by default.
A provider could store a single local cache record containing the bulk evaluation payload, the associated ETag, a derived cache-key hash based on inputs such as the targetingKey and auth token, and the time the entry was written.
On initialization, the provider would load the persisted entry, attempt the normal bulk evaluation request, and fall back to the persisted entry only when the request cannot complete because the client is offline or the network is temporarily unavailable.
Further details and proposed provider behavior will follow in an ADR PR.
Problem
OFREP static-context providers currently use an in-memory bulk evaluation cache. This works while the OFREP service is reachable, but the cache is lost across application restarts and cannot be reused during offline startup or temporary network loss.
This is a poor fit for web and mobile environments, where intermittent connectivity and app restarts are common. A client may have a previously successful bulk evaluation, but without local persistence it falls back to errors or code defaults instead of continuing from the last known state.
Proposed Solution
Recommend that static-context providers persist their last successful bulk evaluation in local persistent storage by default.
A provider could store a single local cache record containing the bulk evaluation payload, the associated
ETag, a derived cache-key hash based on inputs such as thetargetingKeyand auth token, and the time the entry was written.On initialization, the provider would load the persisted entry, attempt the normal bulk evaluation request, and fall back to the persisted entry only when the request cannot complete because the client is offline or the network is temporarily unavailable.
Further details and proposed provider behavior will follow in an ADR PR.