perf: remove old marker logic

[roggervalf]

No need to support old marker logic removal as markers are living in a different key now in recent versions
Also we should validate if a jobId contains : as this separator could break flow logic

bullmq/src/classes/flow-producer.ts

Line 419 in c60e6a3

const [prefix, queueName, id] = key.split(':');

[manast]

What would be the proper way to migrate from a version older than v5 to v6? for instance, if we upgrade from v4, then to v5 and then to v6, there could still be markers left, and break the queue.

[roggervalf]

What would be the proper way to migrate from a version older than v5 to v6? for instance, if we upgrade from v4, then to v5 and then to v6, there could still be markers left, and break the queue.

I added a method to remove legacy markers in case someone come from an older version

[manast]

I added a method to remove legacy markers in case someone come from an older version

I think we also need a code example on how to do the migration. For instance, when should this method be called, and also is there a risk that the queue gets stuck before calling it? maybe we need to do a pause/remove markers/resume cycle or something like this.

[roggervalf]

I added a method to remove legacy markers in case someone come from an older version

I think we also need a code example on how to do the migration. For instance, when should this method be called, and also is there a risk that the queue gets stuck before calling it? maybe we need to do a pause/remove markers/resume cycle or something like this.

code example could be added in migration guide similar to what was done in previous breaking changes like https://bullmq.io/news/062123/faster-priority-jobs/ where removeDeprecatedPriorityKey was mentioned. This method is similar as it's also intended to be used one time. I also added a test case to demonstrate that queues won't get stuck and having queues in a paused state will be the best option to not process that legacy marker as a regular job.

[manast]

LGTM