Run experiment outside context of request

[ndelage]

I'd like to use Split outside an rack request, as part of a background job. To complicate matters even further, my "user" isn't a user at all, it's a different model, so I need to set a custom persistence key.

Fortunately, it appears most of the work to make this possible was accomplished in this #286 by @joshdover. Unfortunately, some things have changed and the example provided in #286 doesn't work anymore.

I made a few tweaks, but I'm still not there:

# My "user" is a Lead, so I need to set a custom key prefix to prevent clashing with experiments made against users 
ab_user = Split::User.new(Split::Persistence.adapter.new(nil, "lead_id_#{lead.id}")

experiment = Split::ExperimentCatalog.find_or_create(:welcome_message)
trial = Split::Trial.new(user: ab_user, experiment: experiment)
puts trial.choose!

The last line, trial.choose! fails because my ab_user isn't a Split::User and doesn't implement the method . cleanup_old_experiments!.

NoMethodError: undefined method `cleanup_old_experiments' for #<Split::Persistence::RedisAdapter:0x007f9980bbb450>

The obvious solution might be to instantiate a new Split::User instead of treating the persistence adapter as a user. But when instantiating a Split::User I can't provide a custom adapter or key:

module Split
  class User
    def initialize(context)
      @user = Split::Persistence.adapter.new(context)
    end
  end
end

I can only provide the context which is useless to me, since I'm not in the context of a HTTP request.

Any ideas on how to best support running experiments outside a request? Supporting an optional adapter or key argument to Split::User.new feels like the easy solution here.

For now, I'm using this monkey patch:

module Split
  class User
    def initialize(context, key=nil)
      @user = Split::Persistence.adapter.new(context, key)
    end
  end
end

[andrew]

@ndelage thanks for the in depth issue!

I'd be happy to add an optional key argument to Split::User if you'd like to submit it as a pull request?

[ndelage]

Sure, I'll send one over. Thanks for the quick response.

[ndelage]

Hmm. My patch only works with the redis store, the session & cookie adapters don't support a 2nd key arg, e.g.

class CookieAdapter
  def initialize(context)
  end
end

Which makes sense, since there isn't a lookup step for these two adapters (they're already scoped to the current user by design). I'm going to give this a bit more thought. But what's your opinion of just supporting a custom adapter as the arg, not key. It feels wrong to have User#initialize know which adapters support a custom key and which ones don't, e.g.

# this is likely the wrong approach
def initialize(context, key=nil)
  if Split::Persistence.adapter.kind_of? Split::Persistence::RedisAdapter
    @user = Split::Persistence.adapter.new(context, key)
  else
    @user = Split::Persistence.adapter.new(context)
  end
end

Instead, accepting a ready to go adapter as an arg frees up the User class from knowing which adapters support which args (since they all don't support the same interface).

# this feels more appropriate
def initialize(context, adapter=nil)
  @user = adapter || Split::Persistence.adapter.new(context)
end

Any other ideas?

[andrew]

Ah yeah, good point, passing in the adapter seems like a good alternative 👍