Failures 2.0 failure objects #1115
Conversation
|
Changes Unknown when pulling 5da7449 on cade:failures-2.0-failure-objects into * on resque:master*. |
|
My initial feedback is that this is super awesome, I'm gonna see what other people think too though. |
|
Also, still getting intermittent failures on CI for the legacy suite hook tests. |
|
Oh, this is kinda dumb, but I prefer |
|
@steveklabnik Thanks for the feedback! |
|
Changes Unknown when pulling 376b945 on cade:failures-2.0-failure-objects into * on resque:master*. |
| # @option opts [Integer] :offset - the number of failures to offset the results by (ex. pagination) | ||
| # @option opts [Integer] :limit - the maximum number of failures returned (ex. pagination) | ||
| # @return [Array<Hash>, Hash{Symbol=>Array<Hash>}] | ||
| def self.all(opts = {}) |
There was a problem hiding this comment.
I'm not sure about the behaviour of this method - it sometimes returns an array, and sometimes a hash.
That makes any method which calls this needs to be unnecessarily complex, eg see the definition of Failure::Base.filter_by_class_name_from
Why not just always return an array - this would keep compatibility with 1.x? If you really need the hash behaviour somewhere, have a separate method that explicitly does that.
There was a problem hiding this comment.
@tomblomfield Thanks for the feedback!
In my opinion, if we wanted to lock this method down to always return the same value type, it should always return a hash. The original 1.x design was based on a single failure queue (:failed), so returning failures in an array made sense. But with the move toward multiple failure queues, pushing failures from different failure queues into a singular array seems counterintuitive to me.
As it's currently written, it obviously tries to take the user's arguments into consideration and just "do the right thing", though I agree, with contextually differing return values, there is possibility for confusion. Also, you have a good point that limiting to a single return value would simplify some of the internals.
@tarcieri / @steveklabnik - Any thoughts on this interface?
There was a problem hiding this comment.
RedisMultiQueue inherits from Base and overloads class method all, changing the method signature.
Choosing to return only a hash feels like an unnecessary gotcha because it's different from both previous versions of Resque and other single-queue implementations - ie your Redis class has the same method, but it returns an array. It would be nice if Redis and RedisMultiQueue had the same basic API, as far as possible.
You could extend RedisMultiQueue to provide the additional functionality - ie implement an .all_by_queue method.
There was a problem hiding this comment.
You're absolutely right that it doesn't comply with previous versions of Resque or the Redis class.
I'm not considering compatibility with the Redis class based on the "Multiple failure queues or GTFO" point from the Failures 2.0 wiki. It's my expectation that the Redis class will likely be deleted, and the thinking behind the failure system will fundamentally shift from 1.x. I've only kept Redis up to date because deleting Redis without further core team/community discussion felt presumptuous on my part.
Thanks for helping to think this through with me. Hopefully the verdict on the fate of Redis will shed some light on how to normalize the return value of RedisMultiQueue::all if the current return situation is deemed to violate POLS.
|
Needs a rebase. I recommend merging this because it is awesome. |
|
|
||
| # Decodes raw result objects from Redis and optionally yields them to a block | ||
| # @api private | ||
| def process_results(results, index, &block) |
There was a problem hiding this comment.
Note: this &block argument is unused and can be removed.
The former implementation of ::all was renamed to slice. ::all now accepts an options hash consisting of :queue, :class_name, :offset or :limit. This is intended to be an initial implementation of @tarcieri's suggestion on how to fix the Failure interface from the Failures 2.0 wiki.
This is to address @tarcieri's "Failures aren't objects" point from the Failures 2.0 wiki. (Also, the latter half of "More like ActiveRecord".)
Also deletes the legacy tests that fail without this backward compatibility
|
@JackDanger rebased and removed the block param you pointed out. Thanks for the feedback! |
|
I'll merge this when the build succeeds; I really appreciate the review from @JackDanger on this and the bump to keep it moving. @cade & @JackDanger: if you could both check your e-mails, you'll find an invitation to have more freedom to contribute to this project; I appreciate both of your contributions and trust your instincts more than I trust my ability to keep you unblocked. |
|
Hey there! Sorry that your PR has (probably) languished. Resque development has been on hold for a long time. That said, @hoffmanc and I (as well as others, hopefully!) are going to be getting back to it. Which brings me to this PR. Resque 2.0 is basically on hold, forever. We'll be swapping the As such, |
This is a big change, so I'm open to suggestions/additions/improvements.