Project

General

Profile

Actions

Bug #20853

closed

Hash key retrieval after Process.warmup

Added by keelerm84 (Matthew Keeler) 5 days ago. Updated about 4 hours ago.

Status:
Closed
Assignee:
-
Target version:
-
ruby -v:
ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x86_64-linux]
[ruby-core:119641]

Description

This was first reported as an issue against the LaunchDarkly SDK and Sidekiq SDKs as an issue in Ruby 3.3.1. I can still in Ruby 3.3.5.

Overview of behavior
The LaunchDarkly SDK maintains a hash of feature and segment information. This hash is indexed by 2 keys which are themselves hashes. They are defined as:

  FEATURES = {
    namespace: "features",
    priority: 1,
    get_dependency_keys: lambda { |flag| (flag[:prerequisites] || []).map { |p| p[:key] } },
  }.freeze

  SEGMENTS = {
    namespace: "segments",
    priority: 0,
  }.freeze

When running the attached script, we often see an error indicating that the flag is not found. If you comment out the Process.warmup line, this error will go away.

The require 'active_support/all' directive is not strictly necessary. Including it causes the failure to more frequently occur, presumably due to the increase work in the warmup phase.

Hash key and access
When debugging the LaunchDarkly code, I noticed some odd behavior. Even though the hash seems populated, the FEATURES key could not index into it correctly.

Below is a bit of code, modified from the SDK, to show how we are trying to interact with the hash. The puts are added to clarify the issue.

    def get(kind, key)
      @lock.with_read_lock do

        @items.keys.each do |k|
          puts "##### Does #{kind[:namespace]} match the key #{k}? #{k == kind} #{k.eql?(kind)} #{k.hash == kind.hash}"
        end
        puts "###### Does @items include it? #{@items.include?(kind)}"

        coll = @items[kind]
        f = coll.nil? ? nil : coll[key.to_sym]
        (f.nil? || f[:deleted]) ? nil : f
      end
    end

Running without Process.warmup

If we run the attached script without the Process.warmup call, we will see that the keys align with the FEATURES key we provided. Additionally, the hash does see that the key exists, resulting in an evaluation result of true at the end.

That output follows.

##### Does features match the key {:namespace=>"segments", :priority=>0}? false false false
##### Does features match the key {:namespace=>"features", :priority=>1, :get_dependency_keys=>#<Proc:0x00007ee6174f9738 /home/mkeeler/code/launchdarkly/ruby-server-sdk.git/main/lib/ldclient-rb/in_memory_store.rb:17 (lambda)>}? true true true
###### Does @items include it? true
true

Running with Process.warmup

If you enable the Process.warmup option, and run the script a few times, you will see output similar to the following.

Note that while the keys are ==, eql?, and their .hash values are equal, the hash does not see that the FEATURES key exists.

##### Does features match the key {:namespace=>"segments", :priority=>0}? false false false
##### Does features match the key {:namespace=>"features", :priority=>1, :get_dependency_keys=>#<Proc:0x0000774f1cbfd730 /home/mkeeler/code/launchdarkly/ruby-server-sdk.git/main/lib/ldclient-rb/in_memory_store.rb:17 (lambda)>}? true true true
###### Does @items include it? false
I, [2024-10-30T14:34:33.842145 #974568]  INFO -- : [LDClient] Unknown feature flag "sample-feature". Returning default value
false

Workarounds

We have worked around this issue by replacing these keys with classes. You can refer to the PR here for those details.

You can also resolve this by triggering a rehash on the hash after the Process.warmup has run.


Files

main.rb (630 Bytes) main.rb keelerm84 (Matthew Keeler), 10/30/2024 06:50 PM
Gemfile (96 Bytes) Gemfile keelerm84 (Matthew Keeler), 10/30/2024 06:50 PM
Actions

Also available in: Atom PDF

Like0
Like1Like0Like1Like0Like0Like0Like0