LoRA × Prompt Test Controller V4

Here's the honest truth about LoRAPromptQueueControllerV4: in the current release of ComfyUI-LoRA-Lens, this node's Python function is literally a no-op. Its FUNCTION is named noop and returns an empty tuple. The code comment says it plainly - LoRA Lab went dashboard-first, and "legacy nodes and routes remain available so existing workflows continue to load, while new runs no longer depend on a graph, numeric node IDs, or browser-side widget mutation."

So why write about it? Because this node is the Rosetta Stone for the whole pack. Every control the new LoRA Lens dashboard exposes was first designed here, and if you've loaded an old workflow and found this thing sitting in it, you need to know what it was and what its fields mean.

What it did. It was the conductor of the graph-based "LoRA × Prompt Test" flow. You'd hand it your prompt list, your candidate LoRAs, and the numeric IDs of the graph nodes it should drive - the identity loader, the positive-prompt encoder, the KSampler, the save node, the grid collector - and its browser-side driver would mutate those nodes, queue a matched batch of prompt×LoRA jobs with the same seed per prompt, collect the results, then trigger face-based analysis and open a report. The principle it encodes is the whole point of LoRA Lens: a fair test keeps everything fixed except the candidate LoRA - same prompts, matched seeds, same resolution and sampler, plus a no-LoRA baseline row.

The fields that matter (each maps to something the dashboard now does automatically):

• prompts, prompt_separator (---PROMPT---), prompt_parse_mode - your prompt set. separator_blocks splits on the separator; one_nonempty_line_per_prompt uses each non-empty line.
• selected_loras, excluded_lora_match - candidate LoRAs, minus any matching the exclusion string. The default krea2_turbo filters out the Krea 2 Turbo LoRA so it isn't double-applied as both acceleration and candidate - on other model families you'll likely want to clear that default.
• prompt_subset_mode / prompt_limit / prompt_sample_seed - test all prompts, the first N, or a random N.
• The five *_node_id fields - the fragile part. Hard-coded node IDs are exactly why this design got retired: rebuild the graph and the IDs drift, and the driver silently drives the wrong node.
• seed_step_per_prompt - matched seeds across prompts, the mechanism behind "every LoRA sees the identical seed."
• grid_mode + grid_cell_width / grid_label_height / grid_font_size - grid rendering, same options the collector uses.
• auto_analyze_after_run / analysis_mode (antelopev2_identity) / analysis_reference_folder (lora_reference) - the InsightFace AntelopeV2 identity analysis, run against a folder of reference faces under ComfyUI/input.

Today's relevance. If your old workflow still has this node, it loads fine and renders its settings - that's the compatibility promise. Just don't expect it to drive the run by itself; the dashboard in the sidebar is the living version of what it did. And regardless of which path you use, the two things that make or break a comparison are: keep a baseline row (a no-LoRA control), and feed clean reference faces - 8–20 single-face, in-identity photos, not training-set leftovers, per the pack's usage docs.

Installation is the shared pack story: ComfyUI Manager (search "ComfyUI LoRA Lens") or git clone https://github.com/astropuzzo/ComfyUI-LoRA-Lens.git into custom_nodes, install requirements.txt with ComfyUI's own Python (insightface, onnxruntime-gpu are the heavy ones), restart, and let the analyser weights download in the background. Skip the venv and you'll be fighting import errors before you ever run a test.