-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added category "delayed" #29
Conversation
…re considered as stuck
module.exports = function (app) { | ||
var getDelayedModel = function(req, res){ | ||
var dfd = q.defer(); | ||
redisModel.getStatus("delayed").done(function(delayed){ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you flatten this pyramid by using then
?
redisModel.getStatus("delayed").then(function(delayed) {
return redisModel.getJobsInList(delayed);
}).then(function(keys) {
return redisModel.formatKeys(keys);
}); // etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also need to call catch
at the end no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah or maybe we shouldn't catch here but let the routes catch and return an error response/render an error page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it looks as it looks but this seems to be the standard way of doing things in this project. For example, compare with this file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good impulse to maintain code style, but when it comes at the cost of correctness… I'm concerned that without catching errors, this UI will not be reliable. (This is true of other views in the project, of course.)
At the least I think we should file an issue about surfacing errors in the UI. And then I think it would be nice to start by surfacing errors in this view while you're in the code—less to remember later. What do you think?
Kudos for figuring out |
Damn, I really need to rewrite this stuff... This is the definition of callback hell. I'm sorry! Thanks a lot for the pull request! |
Thanks for merging! Mind doing a |
Just did it! Sorry, had to increment the version and such first. |
This update adds new job category "Delayed" to correctly display jobs that previously were considered as stuck. Addresses #26