JRuby 9.0.1.0 #to_ary should return Array #3338
Comments
|
@tandibar since I am without a DelayedJob project handy, would it be possible to isolate this behavior into a more simple reproduction case? Perhaps something that is creating the same type of object that is having It's not entirely clear to me whether this is a DelayedJob or a JRuby bug at this point |
|
Hi, i am currently not able to isolate it out of DelayedJob. But i found a very short path to reproduce it:
this will work perfectly but id you add an around callback like and execute again you'll get the error So i think it has something to do with the callback chain which get's build up, but i was not able to track it down. My guess is that the problem is somewhere in this line: https://github.com/collectiveidea/delayed_job/blob/master/lib/delayed/lifecycle.rb#L79 Hope, that helps. |
|
I can reproduce the error on Jruby 9.0.0.0, but everything works on Jruby 1.7.20.1. Jruby 1.7.20.1 Jruby 9.0.0.0 |
|
I have run into this error while trying to debug an issue on JRuby 1.7.22. In that context, the "should return array" exception is not raised. Instead, it silently behaves pathologically. In MRI Ruby, when you iterate over an object it seems that class Example
def to_ary
nil
end
end
test = [Example.new].map { |x, _| x }
puts test == [nil] ? "fail" : "pass"On MRI versions, this passes. On JRuby 1.7.22, it returns |
|
@asthasr thanks for reducing a clear compat error. I am wondering if this is more general than map (we do special optimized bindings for some Java implemented Enumerable methods), but we will try and fix this on both versions. With any luck this is the culprit for delayed_job. |
|
@enebo No problem! It certainly seems to extend to |
|
Ok so I fixed the reported snippet for map and I think many general block dispatches in [master 25aa878] If value.to_ary in block dispatch returns nil then return original value. This did not fix the delayed_job issue but this might be us missing the equivalent logic in RubyProc somewhere...looking into that. @asthasr Can I trouble you to open an issue for 1.7.x on it not behaving properly? The two codebases for handling blocks is quite a bit different and also it will be nice to have an issue in our release notes for it for 1.7.23. The fix will be similarly simple as the above commit. |
|
Ok banking on this being the delayed_job problem since I can see this exploding setting up args in RubyProc.java: class Example
def to_ary
nil
end
end
proc { |x, _| p x }.call(Example.new)
puts test == [nil] ? "fail" : "pass" |
|
@asthasr github issues only allows selecting a single milestone per issue unfortunately. |
|
heh...fixed another issue in proc.call {} for the same behavior in 5f11f7e. This did not fix delyed_job either but I added a spec for the fix so we can at least test against this in the future. |
We are currently trying to migrate from jruby 1.7.16 to jruby 9.0.1.0. We are using ActiveJob with DelayedJob and are getting the following error in the worker:
It seems to be unimportant what the job does or how it is implmented. In the Rails-App we are calling
SomeJob.perform_later(params)which works perfectly. But when the worker (executed viarake jobs:work) catches the job the error happens immediately. The ClassSomeJobis of typeActiveJob::Base. We have another job of typeStruct.newwhich also does not work.Here is the whole backtrace:
The text was updated successfully, but these errors were encountered: