Reused Job Ids Keep Their Data on Redis

0.9.1 fixes a Redis bug that made a running job disappear from getJob() when its id had been used before. No configuration changes or migrations are required.

0.9.1 (2026-10-22)

Bug fixes

History pruning no longer deletes the data of a job pushed again under the same id

With a deterministic job id (an operation id, an outbox message id), a job can be finalized, then pushed again under the same id. When retention (removeOnComplete / removeOnFail with count or age) later pruned the old history entry, the Redis adapter deleted the job data of that id, which now belonged to the new copy. The worker kept running it, but getJob(id, queue) returned null and its dedup lock was released.

Pruning still removes the old history entry, but now keeps the data and dedup lock of an id that is pending, delayed or active. They are deleted once that copy finishes and its own history entry is pruned. A job finalized again also replaces its entry in the other history: a copy that failed and then completed no longer has its data deleted when the old failed entry is pruned, and getJob() reports the latest outcome. (9b82665)

Upgrade

Upgrade every process that runs a Worker. Each worker sends its own pruning script to Redis, so a worker still on 0.9.0 can keep deleting the data of reused ids.