// the find
RichardKnop/machinery
Machinery is an asynchronous task queue/job queue based on distributed message passing.
Machinery is a distributed task queue for Go, similar to Celery but without the Python. You define functions, register them with a server, and send task signatures to workers via Redis, RabbitMQ, SQS, or GCP Pub/Sub. It handles retries, delays, chaining, and fan-out/fan-in workflows (chains, groups, chords).
The workflow primitives — chains, groups, and chords — are genuinely well-designed and cover most real orchestration patterns without requiring a separate workflow engine. The v2 refactor correctly fixed the original sin of importing every broker/backend dependency regardless of what you use; you now inject only what you need. Result backend abstraction is solid: Redis, Memcache, MongoDB, DynamoDB all work interchangeably. OpenTracing support is baked in at the task level, not bolted on afterward.
Last meaningful activity was late 2025 and the repo shows clear maintenance drift — the v1 config docs still say 'TODO' for Redis and GCPPubSub sections, and `GetPendingTasks` only works on Redis despite SQS and AMQP brokers existing. Task argument types are limited to primitives and their slices; passing a struct requires you to serialize it yourself, which defeats the purpose. There is no built-in dead-letter queue handling — failed tasks after retries are logged and that's it, leaving you to implement your own poison-message recovery. The v1/v2 split is awkward: two separate `go.mod` files living in the same repo with near-identical code, and the README still defaults to showing v1 examples in several sections.