Split Dashboard Error: Parameters must be strictly positive

[reneklacan]

Any idea what might be causing this?

I will try to debug it and post any additional info.

[reneklacan]

This seems to be an issue:

PRODUCTION [33] pry(main)> alternative.completed_count
=> 10
PRODUCTION [34] pry(main)> alternative.participant_count
=> 8

We somehow got into a state where we have more completions than participants which shouldn't be possible.

[MyklClason]

I ran into this issue as well. Unclear how to get into a valid state. Though may be related to using the Force for current user, as I saw at one point participant count was -1 when I was using this.

Sanitized split settings (alternatives renamed to X and Y)

Split.configure do |config|
  config.enabled = true
  config.db_failover = true # handle Redis errors gracefully
  config.db_failover_on_db_error = -> (error) { Rails.logger.error(error.message) }
  config.persistence = Split::Persistence::SessionAdapter
  config.include_rails_helper = true
  config.redis = ENV['REDIS_URL']

  config.experiments = {
    enrollment_flow_sign_up: {
      store_override: true,
      alternatives: [
        { name: "X", percent: 90 },
        { name: "Y", percent: 10 }
      ],
      metadata: {
        "X" => {},
        "Y" => {},
      }
    },
  }
end

Probably related to store_override? Couldn't seem to get Force for current user working without it.

[reneklacan]

To resolve it, I just manually modified the stored value in Redis like this:

PRODUCTION [2] pry(main)> experiments = Split::ExperimentCatalog.all_active_first

PRODUCTION [6] pry(main)> experiments[2].calc_winning_alternatives
ArgumentError: Parameters must be strictly positive
from .../vendor/bundle/ruby/2.6.0/gems/simple-random-1.0.3/lib/simple-random/simple_random.rb:103:in `beta'

PRODUCTION [11] pry(main)> experiments[2].calc_beta_params
=> {#<Split::Alternative:0x00005638469c71e0
  @experiment_name="new_conversation_started",
  @name="new_desktop",
  @weight=1>=>[11, -1],
 #<Split::Alternative:0x00005638469c71b8
  @experiment_name="new_conversation_started",
  @name="old_desktop",
  @weight=1>=>[3, 5],
 #<Split::Alternative:0x00005638469c7190
  @experiment_name="new_conversation_started",
  @name="new_mobile",
  @weight=1>=>[5, 1],
 #<Split::Alternative:0x00005638469c7168
  @experiment_name="new_conversation_started",
  @name="old_mobile",
  @weight=1>=>[7, 3]}

PRODUCTION [27] pry(main)> alternative = experiments[2].alternatives[0]

PRODUCTION [33] pry(main)> alternative.completed_count
=> 10

PRODUCTION [34] pry(main)> alternative.participant_count
=> 8

PRODUCTION [41] pry(main)> key = alternative.send :key

PRODUCTION [43] pry(main)> Split.redis.hset key, 'completed_count', 0

[andrehjr]

Hi there,

Yes, this seems related to the use of 'force for current user' as it persists the alternative for the current user directly, which bypasses some stuff. i.e: not incrementing the participant_count when needed

Causing this error, because when an experiment finishes it always increments the completed_count.

[ShylahChiera]

Was experiencing the same issue. Meddled around in Redis data similar to @reneklacan 's answer and found that both my variations (A and B) had higher completed_count than participant_count set them all back to 0 and now up and running again.