Bug Description

The _max_concurrent_semantic variable is stored in QueueManager.__init__ and passed to SemanticProcessor, but it's not used when starting the Semantic queue worker thread.

This causes the Semantic queue to always have max_concurrent = 1, ignoring the configured vlm.max_concurrent value for queue-level concurrency.

Code Evidence

The bug location (queue_manager.py):

def _start_queue_worker(self, queue: NamedQueue) -> None:
    """Start a dedicated worker thread for a queue if not already running."""
    if queue.name in self._queue_threads:
        thread = self._queue_threads[queue.name]
        if thread.is_alive():
            return

    max_concurrent = self._max_concurrent_embedding if queue.name == self.EMBEDDING else 1  # ❌ Hardcoded to 1!
    # ...

The variable is defined and stored but unused:

# In __init__:
self._max_concurrent_semantic = max_concurrent_semantic  # Stored
semantic_processor = SemanticProcessor(max_concurrent_llm=self._max_concurrent_semantic)  # Only used here, not in _start_queue_worker

Expected Behavior

max_concurrent = (
    self._max_concurrent_embedding 
    if queue.name == self.EMBEDDING 
    else self._max_concurrent_semantic  # ✅ Should use stored variable
)

Actual Behavior

• Semantic queue worker always has max_concurrent = 1
• Configuration vlm.max_concurrent is ignored for queue-level task concurrency
• The max_concurrent_llm in SemanticProcessor only affects LLM call concurrency within a single task, not queue-level task parallelism

Impact

Users cannot configure Semantic queue concurrency through ov.conf, leading to slow processing when there are many pending Semantic tasks.

Environment

• OpenViking version: 0.2.9
• Python: 3.12.13
• OS: macOS (Darwin 25.3.0 arm64)