Skip to content
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

requeue doesn't work with new async / await #86

Closed
Monokai opened this issue Aug 11, 2018 · 6 comments
Closed

requeue doesn't work with new async / await #86

Monokai opened this issue Aug 11, 2018 · 6 comments

Comments

@Monokai
Copy link

Monokai commented Aug 11, 2018

Now that Agenda has been updated to use async / await, I think it's time to also update Agendash. I'm getting the error "This function does not accept a callback function. 1/0" when trying to requeue a job in the Agendash UI.

@mbenedettini
Copy link

For those running into this issue, introduced in agenda v2 agenda/agenda@b9ecca9#diff-d24f116ac5cf860dd12424930aaffc40, work around is to stay in agenda v1.0.3

@jskrzypek
Copy link

jskrzypek commented Sep 2, 2018

Shouldn't this be a relatively easy fix? I'll be happy to submit a PR.

There's possibly a concern with backwards compatibility for projects sticking with agenda v1.0.3, but if that's an issue and the idea of doing that round a major version bump doesn't appeal to the maintainers, then checking the installed version of agenda and selecting which api to use shouldn't require too much coding.

@jskrzypek
Copy link

jskrzypek commented Sep 2, 2018

So I'm not that guy who just says "oh that's trivial" and walks away, I see two possibilities that could be straightforward for doing the version checking:

The first option that's not as easy would be to make a PR to agenda itself to add a version number to the exported package, then get them to release that. (this might be better in the long run but it has other complications).

The other way that could be implemented wholly within agendash is to make the dependency on agenda a peer dependency. Then the app could detect the installed version by doing this:

const semver = require('semver');
const agendaVersion = require('agenda/package.json').version;
const useLegacyAPI = semver.lt(agendaVersion, '2.0.0');
...

If we add a parsed option to /app.js where we pass the version to override the version we get from check agenda/package.json, then we can split the tests into two versions as well (or at least two sections), and devDependencies added in the package.json like this:

    "agenda-legacy": ">= 1.0.0 < 2.0.0",
    "agenda": ">= 2.x.x",

That way both the legacy and newer versions of agenda can be supported and have test coverage.

Oh, no, that won't work actually. But we could probably use npx to separate & test the legacy and non-legacy versions.

That was wrong too...

Boy do I feel dumb, this is what the build matrix is for 😂

@jskrzypek
Copy link

Oh, now I see #72 ... so is the idea to move to consuming agenda-rest instead of the code in /lib/agendash.js & /lib/middleware?

@jsardev
Copy link

jsardev commented Sep 21, 2018

Having the same issue. Unfortunately I don't have time right now to take a look at this 😢

@koresar
Copy link
Contributor

koresar commented Jan 19, 2021

This should be fixed in Agendash v2. Please try and report back if it's not working.
Closing this issue as stale.

@koresar koresar closed this as completed Jan 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants