Hey @Th3-M4jor, thanks for this!

However, I still don't understand the need for an incremental index for each worker 🤔 Could you elaborate more why this is necessary? These indexes would be duplicated across different supervisors (in the case you're running jobs in multiple machines).

All processes now have a unique generated name, which is used to locate them, and they carry other identifying information such as the hostname where they're running and their PID. Wouldn't this be more than enough to identify them?

For my particular case having an incremented index for each worker fits better for metrics reporting. It more closely mirrors how Puma identifies each of its forked workers, and I already inject the k8s pod name when reporting metrics to differentiate there.

Though I do see the point that it might not work for everyone's needs, what if I renamed worker_id to worker_index and added a worker_name which returned the unique generated name?

I think you don't need a worker_name 🤔 You can simply access it via #name, no?

About worker_index, if this is just for your particular case, I'd rather not add that, it should be something that's useful in general, not just for one particular way of reporting metrics. I think having the worker yielded in the lifecycle hook makes sense, but I don't see the need for having other attributes besides what is already there.

Fair enough, I removed all references to worker_id and squashed it down to a single commit. Accessing just the queues should work well enough for my case.

Cool! I think, for simplicity, we could have all processes do this, not just workers.

Done, and similarly made a few additional things on each process class private if they were only accessed via tests or from within the class itself.