search

vsivsi / meteor-job-collection

A persistent and reactive job queue for Meteor, supporting distributed workers that can run anywhere.
https://atmospherejs.com/vsivsi/job-collection
Other
385 stars 68 forks source link

Match error: Unknown key in field repeatRetries #186

Closed zvictor closed 8 years ago

zvictor commented 8 years ago

Since the update to version 1.4.0 my application is throwing the following error.

Exception while invoking method 'queue_jobSave' Error: Match error: Unknown key in field repeatRetries
    at exports.check (packages/check/match.js:34:1)
    at JobCollectionBase._DDPMethod_jobSave (packages/vsivsi_job-collection/src/shared.coffee:781:5)
    at [object Object].<anonymous> (packages/vsivsi_job-collection/src/server.coffee:147:22)
    at packages/check/match.js:107:1
    at [object Object]._.extend.withValue (packages/meteor/dynamics_nodejs.js:56:1)
    at Object.exports.Match._failIfArgumentsAreNotAllChecked (packages/check/match.js:106:1)
    at maybeAuditArgumentChecks (packages/ddp-server/livedata_server.js:1701:18)
    at packages/ddp-server/livedata_server.js:711:19
    at [object Object]._.extend.withValue (packages/meteor/dynamics_nodejs.js:56:1)
    at packages/ddp-server/livedata_server.js:709:40
    Sanitized and reported to the client as: Match failed [400]
zvictor commented 8 years ago

Just found the solution. The npm package was updated locally, the meteor package no. Running meteor update solves the issue.

vsivsi commented 8 years ago

Any idea how the npm package got updated ahead of the Atmosphere package? That shouldn't happen automatically, because each version of the Atmosphere package specifies the corresponding npm version.

zvictor commented 8 years ago

well... that's how my package.json was defining the dependency:

"meteor-job": "^1.3.2",

The caret says that it will install the latest version in the range 1.x.x [1], therefore a fresh installation of my project had meteor-job 1.4.0 while meteor was locking meteor-job-collection in version 1.3.2

vsivsi commented 8 years ago

I see, you have non-meteor node.js workers.

Something to keep in mind with Semver is that code written against a 1.y API may not work when used with a 1.x implementation when x < y. For distributed apps, that means that the client-side can't safely use an API version newer than the server Implements, as you discovered.

If the server had been upgraded, but not the worker client, everything would have been fine. But the opposite is problematic, because it is the distributed equivalent to using a 1.y feature in your code, but continuing to require only the 1.x library.

I suppose the client and server could be implemented to negotiate down to the lowest common denominator API, but for job-collection that seems like overkill (and would add a lot of complexity), because the author of node.js worker code is almost certainly on the same team as the implementer of the server-side of the Meteor app, so coordination of versions between them should be straightforward. As I noted above, within the Meteor environment, this is handled automatically, and when it isn't it should "fail fast", which it did in your case.

Thanks for writing back, I just wanted to make sure there wasn't some other type of case that I had missed.

zvictor commented 8 years ago

I agree with you. Negotiating down to the lowest common denominator API would definitely be overkill in a codebase that is already quite complex.

Thank you for taking some time to check it. Great work with the project, btw :)