feat: set API key from settings modal

[Sparkier]

depends on #1291

fix #1146

[rbren]

🤔 this didn't seem to work for me--I plugged in a bad API key, and it just used the key I had set on the backend

[Sparkier]

Hmm thank you for testing. Will debug.

[Sparkier]

I think fixed. Not sure if I caught all edge cases.

[amanape]

You've extended getCurrentSettings to also include the API key. Maybe you can utilize the settings state that now already stores this data directly rather than use a separate state to handle the API key.

[Sparkier]

Yep, good point.

[amanape]

Also, it seems that this branch does not contain the most recent updates made to the SettingsModal.test.tsx file (mock path change and eslint import/order, compare with main).

[amanape]

There is some strange behavior regarding the way settings are stored. First off, some issues I am facing with the API key:

• If I export key from terminal, it does not display on settings (this is because settings searches in storage rather than env)
• Changing the key does not immediately take effect, it requires a reload.

After some exploring, I also found a few issues:

saveSettings (src/services/settingsService)

This function is called when the user presses the "save" button. To summarize, it gets existing settings from local storage, and compares it with the new settings passed as an argument. It then gets the difference, and dispatches updates.

One issue is that you set the value of the API key to local storage directly before the settings are saved (see handleAPIKeyChange of SettingsModal.tsx). This means that saveSettings cannot properly identify the updates because it fetches local storage to compare with new settings, but the API key now exists in both, therefore there is no difference to dispatch.

Settings Store

Speaking of dispatching to settings store, I cannot find where it is actually used. It may be outdated and no longer required, and may be why no getters exist. It seems that the current way of setting and retrieving settings are through the local storage.

I suppose this is something to keep in mind for the future, so that we can slowly retire this store in favor of local storage, but this needs extra attention which is beyond the scope of this PR.

initializeAgent (src/services/settingsService)

Unexpectedly, this does not behave as expected after updating the key, which is most likely the reason we have to refresh the page directly to have the agent use the new key.

I found that changing the function definition (initializeAgent(settings: Settings): void, where settings = { ...currentSettings, ...updatedSettings }) and passing new settings directly does in fact result in the agent (re)initializing after a key change, an does not require a refresh to use the new key. Although, unexpectedly, the local storage settings no longer updated on the new key. Meaning when I did refresh, it used an outdated key. (probably related to some other changes I made elsewhere during debugging, so maybe you can do some fine-tuned debugging of your own)

---

It may not be important to load an API key set by environment variables because we probably want the user to enter their key via UI, especially in the future if/when we move away from being self-hosted.

Other than that, everything seems to be OK. I hope the above information will be useful for you to solve the refresh problem.

[rbren]

@Sparkier I can't actually get this to work 🤔

It seems to always send an empty LLM_API_KEY to the websocket. As @amanape points out, it also doesn't save the new settings if you only change API key.

@amanape I recently did a huge simplification of how settings are saved--definitely possible we can simplify further

[Sparkier]

@Sparkier I can't actually get this to work 🤔

It seems to always send an empty LLM_API_KEY to the websocket. As @amanape points out, it also doesn't save the new settings if you only change API key.

@amanape I recently did a huge simplification of how settings are saved--definitely possible we can simplify further

I think my changes conflicted with the settings simplification. I just merged things and tested and I can change the API key from the UI now.

[amanape]

Seems to work nicely!