In Cadence, the identifier for the set of of task types that a Worker processes, was referred to as a Task List.
It would appear that this is a better Identifier for this Type than Task Queue. A more accurate Identifier would be Tasks Keys Set or my personal preference (Tasks Hashs Set, as I prefer to use Hash vs Key for these types of Identifiers, but this is a subtle semantic that can be elaborated in documentation to my own code). In any case, this would appear to be a set, not a list.
Back to the point at hand, this isn’t actually a Queue at all, it drives an Internal Queue sure, but referring to this set of keys, as a Queue as opposed to a List (which it is), eliminates the usage of Task Queue for actual datastructure that is the Task Queue, the internal Task Queue. Now, if you were to document in a complete manner the workings of the Temporal System, you would repeatedly be specifying that you are in fact NOT referring to the Internal Task Queue when talking about Worker Task Queue (the list of Keys that the client SDKs are passing on Worker construction).
Anyway, my main point is that you have assigned/implied a Datastructure behavior (a Queue) to an Entity that isn’t a Queue at all.
The task queue is a durable queue that is implemented by the Temporal service. It is a queue because it has the semantic of a queue. When multiple worker processes listen on it for tasks a single task is received by only one of the workers.
In further consideration, you are correct in the current implementation. I suppose TaskQueueName is appropriate for how to think about it.
My understanding was incorrect (and more expansive than the current implementation) as to what the purpose of the TaskQueueName was in terms of it’s use in Worker and Workflow (through WorkflowOptions).
In my mind (and I admit this was a completely incorrect topology and should have been obvious), a Worker is an Entity that is Processor of Tasks (Task Tags more appropriately).
It was my hazy understanding that there was an intent of specifying that a Worker is handling a set of Task Tags with which Workflows are tagged. One could bind Workflows to a Task Tag. And then register a comma-delimited Task Tag List to a Worker. The Worker would then handle all of the Workflows that are tagged by that Task Tag List, as declared by the Task List in Cadence. Obviously, this is not the case as we are directly registering Workflows on the Worker.
In that case, (and at this time, I should maybe think about it some more) it isn’t clear why we are binding Task Queue Name to Workflow through Workflow Options, if the Workflows are directly registered on Workers anyway.
WorkflowOptions are used only when a workflow is started. The process that starts workflow in the majority of situations is not the same process that hosts Workers.