Boyo LoRA Path Forwarder

Here's the glue that makes the split architecture work. Boyo LoRA Config Processor hands you config_data DICTs; Boyo LoRA Path Forwarder takes those DICTs, extracts the high- and low-noise LoRA filenames, validates them against the actual loras folder, and outputs stable paths that standard ComfyUI LoRA loader nodes accept. It's the answer to a real problem: LoRA dropdowns are typed against the folder's file list, and during a long batch run that list can shift or break connections. The Forwarder buffers the list at startup so downstream loaders don't choke when things change mid-run.

The inputs

• config_data_1/2/3 - DICTs from Boyo LoRA Config Processor (each carries the processed config's paths). Feed the processor's config_data_1/2/3 outputs here.
• force_refresh - BOOLEAN. The tooltip is blunt: force-refresh the LoRA list if connections break. Toggle it when you've added LoRAs and connections have gone stale without a restart.

Outputs:

• high_noise_path_1/2/3 and low_noise_path_1/2/3 - the six validated LoRA filenames, typed against the LoRA list so they plug into standard loader dropdowns.
• status_message - STRING reporting what was matched and forwarded.

Install

Part of Boyonodes. ComfyUI Manager → search "Boyonodes", or:

cd ComfyUI/custom_nodes
git clone https://github.com/DragonDiffusionbyBoyo/Boyonodes

Restart. No extra dependencies.

Why it exists

Match a config path to the folder list by filename, not by trusting the stored string blindly. If a LoRA can't be matched, it returns none rather than a broken path - which is honest, and matches the none convention downstream loaders already expect. Where people trip up: feeding raw config_data from the Processor into a loader directly instead of through this node, then wondering why the type doesn't fit. The Processor resolves prompts; the Forwarder resolves paths; loaders apply weights. Chain them in that order and the LoRA toolset finally feels like a pipeline.