title: Celery isn't respecting the queue attribute
body: <p>So for some of my tasks on Celery 3.0.19, Celery is apparently not respecting the queue attribute, and is instead shipping the task out to the default celery queue</p>
  
  <pre><code>/This is a stupid test with the proprietary code ripped out.  
  def run_chef_task(task, **env):
  if env is None:
      env = {}
  if not task_name is None:
      env['CHEF'] = task_name
  
  print env
  cmd = []
  if len(env):
      cmd = ['env']
      for key, value in env.items():
          if not isinstance(key, str) or not isinstance(value, str):
              raise TypeError(
                  "Environment Values must be strings ({0}, {1})"\
                  .format(key, value))
          key = "ND" + key.upper()
          cmd.append('%s=%s' % (key, value))
  
  
  cmd.extend(['/root/chef/run_chef', 'noudata_default'])
  print cmd
  ret = " ".join(cmd)
  ret = subprocess.check_call(cmd)
  print 'CHECK'
  return ret,cmd
  </code></pre>
  
  <p>r = run_chef_task.apply_async(args=['mongo_backup], queue = 'my_special_queue_with_only_one_worker')
  r.get() # returns immediately</p>
  
  <p>Go to flower.  Look up task.  Look up worker that the task ran on.  See that the worker is different and that the worker that the task ran on is NOT the special worker.  Confirm that Flower is saying that 'special_worker' is only on 'my_special_queue', and ONLY 'special_worker' is not on 'my_special_queue'.  </p>
  
  <p>Now here's the really interesting part:</p>
  
  <p>Pull up rabbitmq-management on the broker (and confirm that the broker is the broker).<br>
  There was a message sent across the broker on the correct queue to the correct worker (verified).  Immediately afterwards, another message got sent on the celery queue</p>
  
  <p>And in the logfile for the worker, it says that it accepted and COMPLETED the task:</p>
  
  <pre><code>[2013-05-16 02:24:15,455: INFO/MainProcess] Got task from broker: noto.tasks.chef_tasks.run_chef_task[0dba1107-2bb5-4c19-8df3-8a74d8e1234c]
  [2013-05-16 02:24:15,456: DEBUG/MainProcess] TaskPool: Apply &lt;function _fast_trace_task at 0x2479c08&gt; (args:('noto.tasks.chef_tasks.run_chef_task', '0dba1107-2bb5-4c19-8df3-8a74d8e1234c', ['mongo_backup'], {}, {'utc': True, 'is_eager': False, 'chord': None, 'group': None, 'args': ['mongo_backup'], 'retries': 0, 'delivery_info': {'priority': None, 'routing_key': u'', 'exchange': u'celery'}, 'expires': None, 'task': 'noto.tasks.chef_tasks.run_chef_task', 'callbacks': None, 'errbacks': None, 'hostname': 'manager1.i-6e958f0f', 'taskset': None, 'kwargs': {}, 'eta': None, 'id': '0dba1107-2bb5-4c19-8df3-8a74d8e1234c'}) kwargs:{})
  // This is output from the task
  [2013-05-16 02:24:15,459: WARNING/PoolWorker-1] {'CHEF': 'mongo_backup'}
  
  [2013-05-16 02:24:15,463: WARNING/PoolWorker-1] ['env', 'NDCHEF=mongo_backup', '/root/chef/run_chef', 'default']
  [2013-05-16 02:24:15,477: DEBUG/MainProcess] Task accepted: noto.tasks.chef_tasks.run_chef_task[0dba1107-2bb5-4c19-8df3-8a74d8e1234c] pid:17210
  ...A bunch of boring debug logs repeating the registered tasks
  [2013-05-16 02:31:45,061: INFO/MainProcess] Task noto.tasks.chef_tasks.run_chef_task[0dba1107-2bb5-4c19-8df3-8a74d8e1234c] succeeded in 88.438395977s: (0, ['env', 'NDCHEF=mongo_backup',...
  </code></pre>
  
  <p>So it's accepting the task, RUNNING the task, and triggering ANOTHER worker on ANOTHER QUEUE ENTIRELY to run it AT THE SAME TIME instead of returning properly.  The only thing I can think of is that this worker is the only one with the correct source.  All the other workers have old source with the subprocess call commented out, so they return more or less instantly.  </p>
  
  <p>Does anyone have ANY idea what's causing that?  This isn't the only task where we've seen this happen, since it seems to pick 3 random machines off the celery queue to run it on.  Is there something weird that we did with our celeryconfig that could have caused this?</p>