You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a Rails application of mine a model has a state :created with an event :open, :transition_to => :opened declaration.
A method of the model triggers the state change calling open!. That worked well with the 0.8.1 gem but doesn't work anymore with the 0.8.6 one. Instead it ends up calling the open method of open-uri, which happens to have been included somewhere by the framework and has a different number of arguments and returns an error which I saw in the browser.
An easy workaround would be to change the state name to something else but I set "0.8.1" in the Gemfile to be sure I have no other problems I still didn't find out. Furthermore, what if the next version of another gem "steals" one or more of my state names? (inadvertently, obviously, I don't think this is an attack vector). Devising perfectly safe state names is impossible.
The ideal solution is that the Workflow state prevails over any method name. That should make sense because a locally defined workflow should be expected to be in the local scope. Calling a far away method probably violates the least surprise principle.
The text was updated successfully, but these errors were encountered:
In a Rails application of mine a model has a
state :created
with anevent :open, :transition_to => :opened
declaration.A method of the model triggers the state change calling
open!
. That worked well with the 0.8.1 gem but doesn't work anymore with the 0.8.6 one. Instead it ends up calling theopen
method of open-uri, which happens to have been included somewhere by the framework and has a different number of arguments and returns an error which I saw in the browser.An easy workaround would be to change the state name to something else but I set "0.8.1" in the Gemfile to be sure I have no other problems I still didn't find out. Furthermore, what if the next version of another gem "steals" one or more of my state names? (inadvertently, obviously, I don't think this is an attack vector). Devising perfectly safe state names is impossible.
The ideal solution is that the Workflow state prevails over any method name. That should make sense because a locally defined workflow should be expected to be in the local scope. Calling a far away method probably violates the least surprise principle.
The text was updated successfully, but these errors were encountered: