This week on ChatCraft, I fixed a few bugs I found in production that have arisen since the new custom provider feature was implemented. I was able to find these bugs because I reviewed many PRs this week and during testing those PRs I was able to see some abnormal behaviour.
This is the issue I created which outlines how to recreate the 4 bugs I found.
Bug 1
The first bug involved the Instructions page. This page is no longer in use for the most part, but will still come up when the user clears their current provider's api key.
When the user uses a custom provider however, the dropdown list in the Instructions page did not include that custom provider, which leads to unexpected behaviour.
I fixed this by merging the supported providers list with the user's saved providers (which would include the custom provider).
Bug 2
The second bug is also on the Instructions page. The previous behaviour was that when we toggle between the providers in the dropdown, if one of them had a saved api key (from localStorage), then we set that key to settings.currentProvider. This poses a problem, since we are bypassing the key validation code and taking the user away from the Instructions page (Instructions page only shows up for users when the settings.currentProvider api key is blank, and it's no longer blank so we leave). The stored api key could be a stored key that is invalid. Or, the stored key could have become invalid after time passed.
I fixed this by introducing a state variable selectedProvider in Instructions.tsx so we can keep track of the dropdown's selected provider's api key. This allows us to delay the setting of the currentProvider's api key until after we click the Save button.
Bug 3
The third bug involves the User Settings modal. When the user enters a blank or invalid key we get a form error message as expected. However, when we close the modal and reopen it, that message is still there. There is also strange behaviour where if the user input a correct key into that field, the form error message still persists.
I fixed this by adding one line of code to the use effect that runs when the modal is closed, clearing the field validation.
Bug 4
The last bug was brought to my attention while Yumei was testing my PR. I quickly found a fix so I just added it.
The bug involves browsers' password saving ability. When users enter an api key in Instructions page or when they create a custom provider, they were prompted by their browser whether they want to save the password. Users who have a key saved in their browser will experience a bug. The moment they clear their api key the browser will sense that the field is empty and repopulated it with their saved password. Also, when we create one or more providers with the same api url, it will indiscriminately populate the key for those providers.
I don't have a fix for users who have already saved an api key as their password, but I can stop ChatCraft from prompting users to save future keys as passwords. This took a bit of digging online, because many online solutions don't actually work. A lot of the time the browsers will not listen even if you set autoComplete="off". I tried many online solutions one by one, and finally found one that worked.
I found that when Chakra UI's Input component is set to password that is when the browsers will prompt the saving of the password. Therefore I changed it to always be text. Now I lost a feature of component, which used to use type = "password" to disguise the user key with asterix. However I was able to find a different way to hide the user key with asterix (see below!)
PR
My PR for these bug fixes was reviewed by three contributors and landed in release v1.9.0!
Reviews
I did reviews on the following PRs:
Most of these were bug fixes and there is minimal code additions, so I just did testing of the issue to make sure the bug is fixed and no new bugs were introduced.
Unfortunately I found a new bug after a PR had already been merged. PR #577 was a toast message width fix, but for some reason it affected the API Key validation toasts, making them appear when they should not, and in greater numbers. Here is the issue I created which details how to reproduce the issue. It took me a while to track down which PR this bug originated from. At first I was worried this bug originated from one of my PRs. I went through each commit in ChatCraft in sequence until I found where the bug was no longer occurring. Although I managed to narrow down when the bug started occurring, I did not have time to investigate what part of the code from that PR was causing it. I contacted Roy since it was his PR and I believe he is looking into it now.
Top comments (0)