Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: check all required keys #1489

Merged
merged 5 commits into from
Mar 4, 2025
Merged

fix: check all required keys #1489

merged 5 commits into from
Mar 4, 2025

Conversation

yingjiehe-xyz
Copy link
Collaborator

@yingjiehe-xyz yingjiehe-xyz commented Mar 4, 2025

To check whether it is required key, we should check the required_keys map instead of default_keys as some keys are required and do have default value. Right now users cannot launch with ollama

Before:
Screenshot 2025-03-03 at 5 03 55 PM

After:
Screenshot 2025-03-03 at 5 03 21 PM

@yingjiehe-xyz yingjiehe-xyz requested a review from lily-de March 4, 2025 01:05
@lily-de
Copy link
Collaborator

lily-de commented Mar 4, 2025

Made a change because it wasn't playing nice with providers like openai that have a combo of optional and required params

  1. Handles the special case for providers like Ollama with one key that has a default value
  2. For these providers, it only considers them active if the key is explicitly set
  3. For other providers, it checks that all required keys without defaults are set (e.g. OPENAI_API_KEY must be set but others for openai dont matter)

This means:

  1. If OLLAMA_HOST is not explicitly set (even though it has a default), Ollama will not be considered active
  2. If OLLAMA_HOST is explicitly set (as in your example where it's set in yaml), then Ollama will be considered active

The condition configStatus[key]?.is_set === true specifically checks for explicit setting, not just the existence of a default value.

@@ -3419,7 +3419,7 @@ dependencies = [
"cfg-if",
"proc-macro2",
"quote",
"syn 2.0.96",
"syn 2.0.98",
Copy link
Collaborator

Choose a reason for hiding this comment

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

is this Cargo.lock change related to the ui changes?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

it looks like an auto update after run just run-ui

Copy link
Collaborator

Choose a reason for hiding this comment

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

i have no idea -- i pulled main and then switched to the branch and then updated the ui and when committing saw cargo had changes too... i am confident that cargo.lock was not modified when i switched to the branch, and i think it may have happened during just run-ui during the cargo build step

Copy link
Collaborator

@kalvinnchau kalvinnchau left a comment

Choose a reason for hiding this comment

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

lgtm, just a minor comment about the Cargo.lock

@yingjiehe-xyz yingjiehe-xyz merged commit cd4d6c4 into main Mar 4, 2025
6 checks passed
@yingjiehe-xyz yingjiehe-xyz deleted the yingjiehe/fix branch March 4, 2025 04:59
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