Create endpoint for resetting settings

[amanape]

End-user friendly description of the problem this fixes or functionality that this introduces

• Include this change in the Release Notes. If checked, you must provide an end-user friendly description for your change below

---

Give a summary of what the PR does, explaining any non-trivial design decisions
This will make it easier to implement custom reset behaviour for different settings implementations (e.g., saas should reset to a base url / api key instead of clear it)

---

Link of any specific issues this addresses

---

To run this PR locally, use the following command:

docker run -it --rm   -p 3000:3000   -v /var/run/docker.sock:/var/run/docker.sock   --add-host host.docker.internal:host-gateway   -e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:016976a-nikolaik   --name openhands-app-016976a   docker.all-hands.dev/all-hands-ai/openhands:016976a

[enyst]

Thanks for this, I think a reset endpoint might be really useful.

This will make it easier to implement custom reset behaviour for different settings implementations (e.g., saas should reset to a base url / api key instead of clear it)

Interesting! But idk, why would local clear it? (ref also: comment, sorry I didn't get to it before)

if the user wants to reset the settings they set specially in the UI run, maybe it should fallback to what is loaded from the toml. 🤔 What is the use case for clearing, when the user has themselves written stuff in configuration files?

This whole behavior has been strange for a long time, granted, but I don't know why it seems to become stranger, rather than go towards making it more user-friendly and understandable.

[enyst]

Just to note, hardcoding some defaults is a bit strange, as in unusual, arguably a duplicate and should be unnecessary... We had/have some of these in the /frontend, but in the same time the backend had some schema for defaults for the API endpoint to use; then the backend had some methods to use to get the actual defaults from the configuration. (as defined in the dataclasses) . Anyway I think they were unused at some point, so we may have cleaned them both up from the codebase.

We actually do need the dataclass default values? Maybe! If we do need them, what if we were to get the real ones? WDYT?

[rbren]

yeah agreed we should have these defaults saved somewhere else. this line of code should probably just say reset_settings = Settings(), which would pull in the defaults

[enyst]

if the user wants to reset the settings they set specially in the UI run, maybe it should fallback to what is loaded from the toml. 🤔 What is the use case for clearing, when the user has themselves written stuff in configuration files?

This whole behavior has been strange for a long time, granted, but I don't know why it seems to become stranger, rather than go towards making it more user-friendly and understandable.

Actually, scratch that... I think you're right these should be actual defaults.

Just to pick your brain a bit here, I would propose that the understandable way this could work is:

• user can set stuff in the (general) config.toml or not; optional, and with docker run or in the saas it's inaccessible
• UI loads, user sees UI Settings window, sets stuff
  => they go into a user-specific file (currently a json for some reason);
  • the user-specific file takes precedence even if there was anything in the application file
• the user-specific file is always loaded if it exists
• user or some other actor resets the UI Settings
  => it falls back to the values that would apply if there is no general file and no specific file: that's the dataclass (BaseModel now) defaults.

Does that make sense? Does the saas use case need something different?

[amanape]

Good points; if I am understanding correctly, you're suggesting to show the user-set settings (set either via the UI or something like config.toml) unless they reset, in which case they see the default settings I'm proposing to return.

I guess that would imply that the first-time defaults (if no settings exist) are from config toml. This would also mean that we are undoing the changes made in #6704 since the UI relies on a 404 to know whether to show the modal or not.

For saas, the only requirement is that we can create a custom reset method. This is due to the fact that the default LLM API Key in saas is the one All Hands would provide to the user

[enyst]

unless they reset, in which case they see the default settings

Yes, and we will need to save these in the json I think? Because if I reset, then reload the page, I guess it should continue to be defaults.

This would also mean that we are undoing the changes made in #6704 since the UI relies on a 404 to know whether to show the modal or not.

This sounds right. The behavior is nice though (opening Settings window), I know we wanted it for a long time to avoid some user confusion. Any chance we could hook it up to "some settings came from backend, but the api key is empty"?