Hangfire.Pro.Redis’s support for using Redis channels to trigger wakeups in FetchNextJob works by constructing a list of WaitHandles and calling WaitHandle.WaitAny on them. However, WaitAny can only wait on 64 handles at a time, so passing more than 63 queues (1 handle is used for the to FetchNextJob will throw an OperationUnsupportedException and cause job retrieval to fail.
I though 64 queues will be enough for everyone 
I have a solution for this, but could you describe you case, i.e. why are you using such a high number of queues? Just to have a better understanding of a problem.
We’re using Hangfire as the back end for a user-facing batch system, with logical jobs that represent a workflow of hangfire jobs and batches. Each user job is represented by a single Hangfire queue. The peak capacity we need to handle is in the low hundreds, which I’ve confirmed that Hangfire is entirely capable of handling except for this arbitrary limit in the subscription handling.