All-Hands-AI
[Bug]: The search API Key gets reset when you save settings
Is there an existing issue for the same bug? (If one exists, thumbs up or comment on the issue instead).
- [x] I have checked the existing issues.
Describe the bug and reproduction steps
- Add a search API Key and save changes.
- Then change something in the settings. Let's say you change the LLM Provider and Model
- Click Save Changes.
- The Search API Key gets reset
OpenHands Installation
Docker command in README
OpenHands Version
No response
Model Name
No response
Operating System
None
Logs, Errors, Screenshots, and Additional Context
No response
This looks like a straightforward bug that should be relatively manageable to fix. The issue has a clear, reproducible problem: the search API key gets wiped out whenever settings are saved, even when modifying unrelated configuration like LLM provider settings.
What's clear from the report: The reproduction steps are well-defined - add a search API key, change any other setting, save, and the API key disappears. This suggests a classic form handling issue where either the search API key field isn't being properly included in the save operation, or there's a state management problem where the key gets overwritten during the settings update process.
Technical factors to consider: This is likely a UI/UX issue in the settings form logic. The problem could stem from a few common patterns - maybe the form is only serializing visible or "dirty" fields, or there's separate state management for different setting categories that aren't being merged properly. It could also be a simple oversight where the search API key field isn't included in the save payload.
What needs investigation: You'll want to examine the settings form component and trace through the save flow. Check how form data is collected, whether all fields are being included in the request, and how the backend processes the settings update. Look at the network requests when saving to see if the API key is even being sent.
Next steps: Start by reproducing the issue locally, then inspect the settings save functionality in the frontend code. Check the form serialization logic and the API call that handles settings updates. This feels like the kind of bug where the fix might be adding a single field to a form data object or ensuring proper state merging.
![openhands-ai[bot] avatar](https://avatars.githubusercontent.com/in/1062359?v=4 "Published by a pub.dev verified publisher"){kind=small}
@mamoodi is this still an issue? It looks like the PR above was closed.
@michaldorsett no it wasn't successful. The settings page is a little intertwined and I think it's going to go through an overhaul at some point so didn't want to pursue it further since it's a minor bug.
@mamoodi So perhaps it's best to remove the good first issue label, and somehow mark this as backlog?
Why has this issue persisted for so long without being resolved? Has no one discovered this problem while using custom LLM interfaces?
Because it's a minor issue. Also I don't think most people are using the Tavily search API Key field.
i am usig it :) it's kinda confusing, because the pattern of they key does nto match what tavily gives you :)
OH interface asks for sk-tavily but tavili offers tvly-dev...
i am usig it :) it's kinda confusing, because the pattern of they key does nto match what tavily gives you :)
OH interface asks for sk-tavily but tavili offers tvly-dev...
Ah that should be an easy fix.
@openhands lets solve this subissue:
OH interface asks for sk-tavily but tavili offers tvly-dev...
Change the OH interface to ask for a key of the form tvly-dev
To clarify the current issue: When you change something else in the settings, the search API Key also gets reset. The Search API key should not be affected by changing of other settings.
Confirming on 0.56.0, this issue is annoying, especially when you often do different tasks and need different models' support.
Hey folks! š
I noticed this bug is already addressed in carlos2104445/OpenHands#4, where Devin bundled a fix for search_api_key together with a few other issues and left a manual test plan for humans. It looks like that work lives in the fork only and still needs some hands-on QA.
I just climbed out of the hole from bug #10555 š so Iām already deep in the Settings flow. Iām happy to:
Pull those changes locally
Run through the suggested test plan for the Search API Key behavior
Open a focused PR back to this repo that ports just the search_api_key fix plus a small regression test
Would that be helpful? If so, I can pick this up and report back with results. š§š
Awesome Sauce! š Would you be able to assign this to me @mamoodi ? š Thank You! š