aasm icon indicating copy to clipboard operation
aasm copied to clipboard

after callback not working in transition scope

Open jkojro opened this issue 4 years ago • 7 comments

event :run, after: :notify_somebody do
     transitions from: :sleeping, to: :running, after:  :notifi_somebody_else

Actual behaviour: Record in notify_somebody method is in running state, but notifi_somebody_else is triggered when record is still in sleeping state.

Expected behaviour: after callback is triggered after record changes state (is in running state)`

jkojro avatar Mar 31 '21 12:03 jkojro

same problem using aasm 5.0.5

oscarada87 avatar Nov 18 '21 06:11 oscarada87

@jkojro @oscarada87 Issue seems to have been resolved tested below example with aasm version 5.2.0

class Job
  include AASM
  aasm do
    state :sleeping, :initial => true
    state :running

    event :run, after: :notify_somebody do
      transitions from: :sleeping, to: :running, after:  :notifi_somebody_else
    end
  end

  def notify_somebody()
    puts "notify_somebody"
  end

  def notifi_somebody_else()
    puts "notifi_somebody_else"
  end
end

j = Job.new
puts j.aasm.current_state # :sleeping
j.run
puts j.aasm.current_state # :running

ChandanChainani avatar Mar 24 '22 05:03 ChandanChainani

@ChandanChainani , first of all, thanks for the response. I've tested in aasm version 5.2.0, but the problem was not resolved.

Expected behaviour: state is already :running when :notifi_somebody_else was called

Here is my testing code, slightly changed from yours

class Job
  include AASM
  aasm do
    state :sleeping, :initial => true
    state :running

    event :run, after: :notify_somebody do
      transitions from: :sleeping, to: :running, after:  :notifi_somebody_else
    end
  end

  def notify_somebody()
    puts "notify_somebody"
  end

  def notifi_somebody_else()
    puts "job state: #{aasm.current_state}"
    puts "notifi_somebody_else"
  end
end

j = Job.new
j.run
# job state: sleeping
# notifi_somebody_else
# notify_somebody

oscarada87 avatar Mar 25 '22 02:03 oscarada87

@ChandanChainani , first of all, thanks for the response. I've tested in aasm version 5.2.0, but the problem was not resolved.

Expected behaviour: state is already :running when :notifi_somebody_else was called

Here is my testing code, slightly changed from yours

class Job
  include AASM
  aasm do
    state :sleeping, :initial => true
    state :running

    event :run, after: :notify_somebody do
      transitions from: :sleeping, to: :running, after:  :notifi_somebody_else
    end
  end

  def notify_somebody()
    puts "notify_somebody"
  end

  def notifi_somebody_else()
    puts "job state: #{aasm.current_state}"
    puts "notifi_somebody_else"
  end
end

j = Job.new
j.run
# job state: sleeping
# notifi_somebody_else
# notify_somebody

@oscarada87 the state :running is correct since notifi_somebody_else callback will be called after the state has been updated.

ChandanChainani avatar Mar 25 '22 07:03 ChandanChainani

@ChandanChainani if you look though, the state is coming through as sleeping. I have the same issue where the state in my after callback is the original state using (basically) the same code

aasm do
    state :inactive, :initial => true
    state :active

    event :activate, after: :method_a do
      transitions from: :inactive, to: :active, after: :method_b
    end
  end

  def method_a
    puts "method a: job state should be `active`, job state is #{self.aasm_state}"
  end

  def method_b
    puts "method b: job state should be `active`, job state is #{self.aasm_state}"
  end
DEVELOPMENT [2] pry(main)> Subscription.last.activate!
[07:05] DEBUG   Subscription Load (0.5ms)  SELECT `subscriptions`.* FROM `subscriptions` ORDER BY `subscriptions`.`id` DESC LIMIT 1 
method b: job state should be `active`, job state is inactive
[07:05] DEBUG   TRANSACTION (1.3ms)  BEGIN 
[07:05] DEBUG   Subscription Update (0.3ms)  UPDATE `subscriptions` SET `subscriptions`.`updated_at` = '2022-09-13 06:05:25.196642', `subscriptions`.`aasm_state` = 'active' WHERE `subscriptions`.`id` = 1 
method a: job state should be `active`, job state is active
[07:05] DEBUG   TRANSACTION (0.6ms)  COMMIT 

In both methods, I would expect the state to be active, but it is not.

Spence1115 avatar Sep 13 '22 06:09 Spence1115

@Spence1115 Did you find a solution this? I'm also experiencing the same behaviour.

MatthewRuddy avatar Feb 22 '23 02:02 MatthewRuddy

The problem stated by @MatthewRuddy and @Spence1115 seems correct.

However since we suggest to use after_commit_everywhere should add after_commit support in transaction?

@anilmaurya should I try to fix the same. Please suggest

ChandanChainani avatar Mar 04 '23 14:03 ChandanChainani