Question: Is it possible to set a dynamic `wait` value?

[kimili]

So, I'd like to be able to set a dynamic wait: value on a campaign step. Basically, in the app I'm integrating Heya into, it starts with a 7 day free trial. But by using certain features, users can extend their trials by up to 14 days. I'd like to start a new campaign when a user starts their first extra day, which has 2 steps - One that gets sent right away, and the other that gets sent at the end of their trial. Since the trial end date can change over time, how can I handle sending that second step at the correct time? Here's what I'm trying for that campaign:

class TrialConversionCampaignExtended < ApplicationCampaign
  step :added_first_extra_day
  step :ended,
    wait: ->(member) {
      ActiveSupport::Duration.build((member.group.trial_ends_at - Time.current).to_i)
    }
end

Of course, the wait: value is expecting an ActiveSupport::Duration object (e.g. 3.days). But in that case I'm seeing this error:

undefined method `to_i' for an instance of Proc (NoMethodError)

The relevant stack trace points to the build_arel function in /lib/heya/active_record_extension.rb

Any thoughts on how to make this situation work?

[joshuap]

Hi @kimili. I'm guessing the issue is that it doesn't currently support the lambda/block syntax, but since it's returning a duration that can be converted to an integer, I don't see why we can't make this work. I'd accept a PR for it, or otherwise I'll take a look when I have some spare time. Thanks!

[joshuap]

Hi @kimili. I'm guessing the issue is that it doesn't currently support the lambda/block syntax, but since it's returning a duration that can be converted to an integer, I don't see why we can't make this work. I'd accept a PR for it, or otherwise I'll take a look when I have some spare time. Thanks!

Oops, I think I misspoke. I recall investigating this in the past, and I'm pretty sure Heya's design will make this impossible. The problem is that since the durations are actually embedded in the scheduler query, we don't have the member (or user) available beforehand. So while we could technically support the block syntax (and probably should!), there is no way to pass the user to the block before the query runs.

(Note: while the to_process scope does accept a user, that's used to scope the entire schedule run to a single user—it's not called for every user when calculating the wait durations for each user's subscription.

[joshuap]

Btw, the way we handle this at Honeybadger is I have a TrialEndingCampaign that gets sent when we receive the customer.subscriptions.trial_will_end webhook event from Stripe. That way, people always get the trial ending emails at the right time, even if we i.e. extend their trial in the Stripe dashboard.