fix: Modify data kind constants to avoid Process.warmup rehash #301
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The data stores in the SDK have to deal with multiple types of data -- features (or flags) and segments. These types have long been simple hashes in our SDK, with one defining an optional lambda property. With Ruby 3.3 and the introduction of `Process.warmup`, we have seen an issue where, after warmup, the in memory store needs a `rehash` method call before these kind constants can be used reliably to access the store. To combat this, I am moving these kinds into a class. This class as explicit hash key behaviors, so theoretically shouldn't have this problem Local testing has shown this to be the case. This class is also given a dictionary interface to maintain compliance with the existing implementation. While people should not be relying on these constants explicitly, they do flow through the system in ways that might make their signatures somewhat public.
kinyoklion
approved these changes
Oct 30, 2024
keelerm84
pushed a commit
that referenced
this pull request
Oct 30, 2024
🤖 I have created a release *beep* *boop* --- ## [8.8.1](8.8.0...8.8.1) (2024-10-30) ### Bug Fixes * Modify data kind constants to avoid Process.warmup rehash ([#301](#301)) ([06f11f0](06f11f0)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
|
Is this a bug in Ruby? |
|
I am wondering the same thing. I was planning on writing out a standalone reproduction case and then raising the issue. |
|
I would raise the issue immediately and then work on a repro. The core team may be able to figure out the issue from the behavior without any additional work from you, save yourself the trouble. |
|
Posted the issue at https://bugs.ruby-lang.org/issues/20853 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The data stores in the SDK have to deal with multiple types of data --
features (or flags) and segments. These types have long been simple
hashes in our SDK, with one defining an optional lambda property.
With Ruby 3.3 and the introduction of
Process.warmup, we have seen anissue where, after warmup, the in memory store needs a
rehashmethodcall before these kind constants can be used reliably to access the
store.
To combat this, I am moving these kinds into a class. This class as
explicit hash key behaviors, so theoretically shouldn't have this
problem Local testing has shown this to be the case.
This class is also given a dictionary interface to maintain compliance
with the existing implementation. While people should not be relying on
these constants explicitly, they do flow through the system in ways that
might make their signatures somewhat public.