Skip to content

Do not mistake a URL port for a LoRA alpha suffix - #4546

Open
Daksha1611 wants to merge 1 commit into
openvinotoolkit:mainfrom
Daksha1611:fix-lora-url-port
Open

Do not mistake a URL port for a LoRA alpha suffix#4546
Daksha1611 wants to merge 1 commit into
openvinotoolkit:mainfrom
Daksha1611:fix-lora-url-port

Conversation

@Daksha1611

@Daksha1611 Daksha1611 commented Sep 11, 2026

Copy link
Copy Markdown

🛠 Summary

Fixes #4545.

The optional :alpha suffix of a --source_loras entry was found with rfind(':') over the whole source string, guarded only by a check that the text after the colon does not start with //. That guard covers the scheme colon of a URL with no port, but not the port colon itself, so

xray=https://registry.internal:8080/loras/f.safetensors

aborts startup with Invalid alpha value '8080/loras/f.safetensors'.

Restricts the alpha colon to the final path segment, via source.find_last_of("/\\"). The scheme colon, the port colon and a Windows drive letter all sit before the last separator, so all three are excluded structurally instead of by special-casing. The // check is dropped because it is now unreachable — nothing after the last separator can contain a path separator. lastColon > 1 is kept so a source with no separator behaves as before.

This only affected entries without an explicit alpha; with :0.45 appended, rfind() happened to land on the alpha colon and parsing worked. Adds UrlLoraWithPortWithoutAlpha for the broken case and UrlLoraWithPortAndAlpha to pin the one that already worked.

I have no OVMS build container available, so this is not compiled against the full tree and CI will need to confirm the build. I did check the rewritten block in isolation against the HF repo, URL, posix path and Windows drive-letter forms, with and without an alpha suffix; only the two port cases change behaviour. Draft for that reason.

🧪 Checklist

  • Unit tests added.
  • The documentation updated.
  • Change follows security best practices.

The optional :alpha suffix of a --source_loras entry was located with
rfind(':') over the whole source string, guarded only by a check that the
text after the colon does not start with "//". That guard covers the scheme
colon of a URL with no port, but not the port colon itself.

For an entry with a port and no explicit alpha, such as

  xray=https://registry.internal:8080/loras/f.safetensors

rfind(':') lands on the port colon, alphaStr becomes
"8080/loras/f.safetensors", ovms::stof rejects it because it requires the
whole string to be consumed, and startup aborts with the misleading message
"Invalid alpha value '8080/loras/f.safetensors'".

Restrict the alpha colon to the final path segment. The scheme colon, the
port colon and a Windows drive letter all precede the last separator, so all
three are excluded structurally rather than by special-casing. The "//" check
is dropped because it is now unreachable: nothing after the last separator
can contain a path separator, so alphaStr can never start with one.

Note this only affected entries without an explicit alpha - with ":0.45"
appended, rfind() happened to land on the alpha colon and parsing worked.

Tests: adds UrlLoraWithPortWithoutAlpha (the failing case) and
UrlLoraWithPortAndAlpha (the case that already worked, pinned against
regression).
@Daksha1611
Daksha1611 marked this pull request as ready for review September 12, 2026 07:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

--source_loras misreads a URL port as the :alpha suffix and refuses to start

1 participant