Hi Lorna,

Have you thought about the strong coupling of jobs and deployment revision/version? Say you update your worker class such that a “Job” from a previous revision which was perfectly valid is now incompatible with your changes. To solve this one would probably want to have workers running for both versions until all Jobs from the old revision have been processed.

To achieve this your framework could then transparently append a deployment revision to all queue/tube names. Looking at the beanstalk protocol your worker manager program could then use the “list-tubes” to spawn workers of a specific type and revision to “mop up” jobs from a previous revision.

This all sounds like quite a lot of work for something I assume somebody has already looked into, but looking online I couldn’t find anything.