Skip to content

fix: add missing return in load_model_with_fallback#230

Closed
sjswerdloff wants to merge 1 commit intowaybarrios:mainfrom
sjswerdloff:fix/load-model-missing-return
Closed

fix: add missing return in load_model_with_fallback#230
sjswerdloff wants to merge 1 commit intowaybarrios:mainfrom
sjswerdloff:fix/load-model-missing-return

Conversation

@sjswerdloff
Copy link
Copy Markdown
Contributor

When mlx_lm.load() succeeds without raising ValueError, the function falls through without returning the (model, tokenizer) tuple, causing a TypeError in the caller ('cannot unpack non-iterable NoneType').

This affects any model that loads successfully on the first try (the common case). The ValueError catch paths all have returns, but the success path was missing one.

When mlx_lm.load() succeeds without raising ValueError, the function
falls through without returning the (model, tokenizer) tuple, causing
a TypeError in the caller ('cannot unpack non-iterable NoneType').

This affects any model that loads successfully on the first try
(the common case). The ValueError catch paths all have returns,
but the success path was missing one.
@waybarrios
Copy link
Copy Markdown
Owner

This is a duplicate of #237. The same issue applies here, line 54 already has return load(model_name, tokenizer_config=tokenizer_config) and all paths return or raise correctly:

line 54: return load(model_name, tokenizer_config=tokenizer_config)   # success
line 59: return _load_with_tokenizer_fallback(model_name)             # TokenizersBackend fallback
line 68: return _load_strict_false(model_name, tokenizer_config)      # extra weights fallback
line 69: raise                                                        # unhandled ValueError

return load(...) has been on main since the original commit (90d6dc3), so the function already handles all cases correctly. Closing as duplicate.

@waybarrios waybarrios closed this Mar 31, 2026
@Thump604
Copy link
Copy Markdown
Collaborator

Worth noting that #235 and #237 are independent submissions of the same one-line fix. Three people hit this bug and submitted PRs within 3 days of each other because nothing was merged.

If review bandwidth is the bottleneck, I am happy to help triage incoming PRs or act as a community reviewer. I have production experience with the codebase (122B on M2 Ultra, continuous batching, MTP) and already review most new submissions. Let me know if that would be useful.

@waybarrios
Copy link
Copy Markdown
Owner

sounds good @Thump604

Copy link
Copy Markdown
Collaborator

@Thump604 Thump604 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One-line fix, correct. Merging.

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.

3 participants