Skip to content

fix: Log the cached-data evaluation warning only once per client - #438

Merged
kinyoklion merged 2 commits into
mainfrom
rlamb/log-cached-data-warning-once
Sep 15, 2026
Merged

kinyoklion merged 2 commits into
mainfrom
rlamb/log-cached-data-warning-once

Conversation

@kinyoklion

@kinyoklion kinyoklion commented Sep 11, 2026

Copy link
Copy Markdown
Member

Summary

While data availability is CACHED (the store holds data but the client has not finished initializing), the SDK logs "using last known values" on every evaluation. A client that runs for a long time in that state floods the log with one warning per evaluation.

Each of the two messages (evaluation and all_flags_state) now logs once per LDClient instance. The guard is a Concurrent::AtomicBoolean checked with make_true (a compare-and-set, no lock), the same pattern the context filter uses for its non-symbol attribute warning. The check runs only inside the cached-data branch, so the normal evaluation path is unchanged. Each message now ends with "This message is logged once." to match that precedent. The sibling "store unavailable" messages and the gating conditions are unchanged.

New specs cover: one warning across repeated evaluations, one warning across repeated all_flags_state calls, the two messages counted independently, and a second client logging again.


Note

Overview
Stops log flooding when the client evaluates flags or builds all_flags_state while data is CACHED (store has values but initialization has not finished). Those “using last known values” warnings now emit at most once per LDClient, with separate one-shot flags for flag evaluation vs all_flags_state.

Guards use Concurrent::AtomicBoolean#make_true (same idea as other one-time SDK warnings). Wording adds “This message is logged once.”; store-unavailable errors and when evaluations actually use cached data are unchanged.

Adds specs for repeated calls, independent message types, and a fresh warning on a new client instance.

Reviewed by Cursor Bugbot for commit f673207. Bugbot is set up for automated code reviews on this repo. Configure here.

@kinyoklion
kinyoklion marked this pull request as ready for review September 15, 2026 16:07
@kinyoklion
kinyoklion requested a review from a team as a code owner September 15, 2026 16:07
@kinyoklion
kinyoklion merged commit bcb6e73 into main Sep 15, 2026
11 checks passed
@kinyoklion
kinyoklion deleted the rlamb/log-cached-data-warning-once branch September 15, 2026 16:10
jsonbailey pushed a commit that referenced this pull request Sep 16, 2026
🤖 I have created a release *beep* *boop*
---


##
[8.18.0](8.17.0...8.18.0)
(2026-09-16)


### Features

* Expand version support for JSON gem v3
([e6c7412](e6c7412))


### Bug Fixes

* Log the cached-data evaluation warning only once per client
([#438](#438))
([bcb6e73](bcb6e73))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Overview**
> **Release 8.18.0** — bumps the SDK from **8.17.0** to **8.18.0**
across `LaunchDarkly::VERSION`, `.release-please-manifest.json`, and the
provenance verification example in `PROVENANCE.md`, and adds the
**8.18.0** section to `CHANGELOG.md`.
> 
> This is a Release Please cut, not new feature code in the diff. The
changelog records what ships in the gem: **JSON gem v3** dependency
support and a fix so the **cached-data evaluation** warning is logged
**once per client** instead of repeatedly.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
7688641. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
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.

2 participants