This sprint I worked on chatcraft.org where I had the opportunity to fix a regression using git bisect for the first time.
tarasglek
/
chatcraft.org
Developer-oriented ChatGPT clone
ChatCraft.org
Welcome to ChatCraft.org, your open-source web companion for coding with Large Language Models (LLMs). Designed with developers in mind, ChatCraft transforms the way you interact with GPT models, making it effortless to read, write, debug, and enhance your code.
Whether you're exploring new designs or learning about the latest technologies, ChatCraft is your go-to platform. With a user interface inspired by GitHub, and editable Markdown everywhere, you'll feel right at home from the get-go.
Features
We think ChatCraft is the best platform for learning, experimenting, and getting creative with code. Here's a few of the reasons why we think you'll agree:
🛠️ You're in Control: Customize all aspects of a chat. Use your own System Prompts, edit, delete, and retry AI messages with models from competing vendors in the same chat.
🌍 Multiple AI Providers: ChatCraft supports both OpenAI and OpenRouter, giving you access to a…
Issue 1
I mostly spent time looking into this issue which listed a number of bugs in the user settings modal:
openrouter mostly broken in settings
#848
For repro
- use chatcraft.org in private window.
- open settings
it selects openai
- It now shows up the magic "get openrouter key" box...We should probably surface that better
- Click it, login
- Observe how openrouter key was not added
This issue outlined three bugs:
- Clicking any of the checkboxes for choosing the LLM provider in the settings modal would always result in the first provider being selected.
- The "Get OpenRouter Key" button would only show when the API key input field was focused, which was bad for the option's discoverability.
- The button doesn't actually work.
Bug 1: Broken LLM selection in settings
I spent two days looking into this bug. I had a hunch it was a regression because I figured surely the UI for this must have worked at some point, but there hadn't been any recent changes to the component. I tried to investigate by checking out the last commit that touched the LLM selection code, but I ran into errors installing the dependencies. pnpm said it couldn't find the dependencies, which I assume was because the versions were just that old.
After that I gave up on the regression idea (in hindsight, I should've kept digging) and instead tried looking into the current code. I had no luck trying to debug the existing logic, so I tried to re-create the component from scratch. I noticed it worked until I wrapped the <Table> element which contains the checkboxes in a <FormControl>, both of these being Chakra UI components. So I figured the bug must be in the JSX being rendered and not in the component logic, but again, there hadn't been any recent changes to the JSX.
Since we were using Chakra UI I wondered if the behaviour of the components we were using might have changed, so I tried finding a commit without the bug again. I checked out a random commit from this past September and built and ran the app, and sure enough, the bug wasn't there, which confirmed that this was a regression.
This meant I finally had an opportunity to use git bisect to find the commit that caused the bug. git bisect is a git command that uses binary search to identify which commit introduced a bug in your program. I was excited to try it out, and it led me to this commit which updated a bunch of dependencies:
Update deps for March 2025
#847
Updating deps for March, most things are easy, but I had to leave apache-arrow at 17 vs. 19 for duckdb compat, and the new TypeScript isn't compatible with eslint yet (PR hasn't landed). The rest is probably fine to leave.
Please test and make sure this works for you.
The most obvious suspect was Chakra UI being bumped from 2.10.5 to 2.10.6. I tested with 2.10.5 and the bug wasn't there - then, I installed 2.10.6, and it stopped working, which confirmed my suspicions. I tried looking for release notes for this version, but there weren't any - not on GitHub, and not on their website. I went to their issues page on GitHub and searched for "2.10.5" which led me to this issue:
CheckboxGroup breaks when wrapped by FormControl: Electric Boogaloo
#9747
Seems like the same bug from #8938 has reappeared in 2.10.6. 2.10.3-2.10.5 all work.
https://codesandbox.io/p/devbox/wonderful-dan-forked-yl6kxl
2.10.6
Google Chrome 133
- [ ] macOS
- [x] Windows
- [ ] Linux
One of the maintainers of Chakra UI commented on this saying that this was patched in 2.10.7, so I updated to it and the bug was fixed.
Fix LLM provider selection bug
#865
Related issue: #848
I was able to bisect the selection issue to https://github.com/tarasglek/chatcraft.org/commit/682acced4bde6a5d1289be3df1142969fb046090 (https://github.com/tarasglek/chatcraft.org/pull/847).
The bug originated when updating @chakra-ui/react from 2.10.5 to 2.10.6. An issue was filed for this bug at https://github.com/chakra-ui/chakra-ui/issues/9747
This issue was addressed in 2.10.7. Upgrading fixes the problem.
Even though the fix ultimately ended up being really simple, I'm glad I knew about git bisect because I don't think I could have found the cause of this bug without it. I probably would've kept looking for potentially breaking changes in the settings component or related components.
Bug 2: "Get OpenRouter Key" button only shows when OpenRouter API key field is focused
I'm not sure if this counts as a bug since this was an intentional decision, but I think making the button always visible is a good idea so users can find out that option exists in the first place. To do this, I just had to remove a condition that checked whether the API key field was focused before displaying it. I finished this before the selection bug and made a separate pull request since I wasn't sure at the time whether I'd be able to fix that one.
In User Settings > Models > LLM Providers, show "Get OpenRouter Key" button even when OpenRouter is not selected
#864
Related: #848
Button still doesn't actually get the key but I figured this might be worth landing separately
The third bug, the button not working, is something I didn't have time to work on this sprint. It might be worth investigating next sprint.
Issue 2
Although well overdue, I finished the issue I signed up for last sprint, which was refactoring the program to use the new useChat custom React hook.
Refactor Code To Use `useChat()` Hook
#835
Since @humphd landed #822, introduced ChatProvider & useChat() hook. We need to refactor code to stop passing chat on props in components and utilize useChat() hook wherever it's possible .
I spent a while trying to fit the hook into places where it didn't make sense and in the end only found one place where using it did make sense. The hook gets a chat object by getting it's ID from the route parameter and making a database query, but most components in the code receive the chat through props from two higher-level components. Those higher-level components get chat using React Router's loader function, meaning I couldn't swap their logic out for the hook without making the code more complicated which would defeat the purpose of the refactor. Even if I did, we'd still need to drill the chat prop to their child components, because the logic for chat being undefined is only handled in the higher-level components and handling it at every level would once again just make the code messier.
Use useChat in MessageBase.tsx
#860
Fixes #835
The useChat hook can't be used in any components that are children of ChatBase. ChatBase receives the chat prop from it's parent components LocalChat and RemoteChat. These components retrieve chat using useLoaderData(), while the hook retrieves chat from the route parameter using useParams(). From what I understand, this means the hook can't replace the usage in LocalChat and RemoteChat.
This leaves MessageBase as the only component where useChat can be used in it's current implementation.
Using the hook in LocalChat and RemoteChat will require refactoring them and their usage in router.tsx. I'll try this and see if it makes sense to do this.
Extra
I also tried looking into this issue until I noticed it had already been fixed and just wasn't closed:
Add email to GitHub token info
#855
When a user logs in, we need to also grab the email for the user and include in the data. The Google auth function already does this.
There was a typo mentioned in one of the comments on the issue which wasn't fixed, so I went ahead and fixed that while I was working on the other stuff.
Top comments (0)