This week in ChatCraft
Release 1.5
This week in ChatCraft, Release 1.5 has been released and is available here
Pull Requests
Prompt Updating
I'm happy to share that this week, I was able to extract and get a version of my updated system merged. My change isn't perfect, but it's able to get GPT-3.5-Turbo to return inline math Markdown in KaTeX syntax instead of LaTeX Math mode. One concern we have with this merge is that it might encourage/cause an LLM to add KaTeX syntax into generated code, such as if it's writing code to do any math, but we'll be monitoring this in the coming weeks. The good thing about Open Source is that you can always iterate on and improve code. One thing I learned in my earlier Open Source class is that pursuing perfection often gets in the way of achieving any results at all, or in other words, perfect is the enemy of good. This current change may not be perfect, but it's good enough, and getting it merged means I can finally work on other issues and features.
Cannot Access Shared Bugs - Naive Fix
In a previous blog post, I reported an issue in which shared chats could no longer be accessed. Though a later Pull Request was able to fix the issue at first, some people in the team still had issues accessing their shared Chats. In a meeting this week, we were able to determine that these "broken" shared Chats would redirect to a link with this url pattern:
[website-url]/api/share/{user}/{id},
where {user} is the username of the user who created the chat, and {id} is the chat id.
These redirect url is accessed when the user clicks on one of their shared chats on the ChatCraft UI:
Attempting to access a chat this way returns a 404 error saying the route can't be found:
But the weird thing is, the chat exists, and can be accessed through this link if you enter it directly into your address bar:
This also showed us that the [website-url]/api/share/{user}/{id}-style URLs redirect to another url format, [website-url]/c/{user}/{id}}, which contains the actual chat.
My Investigation
I found the redirect behaviour of the [website-url]/api/share/{user}/{id}-style URL (the "api/share/" URL) to the [website-url]/c/{user}/{id}}-style URL (the "/c/" URL) interesting. Over the past couple of days, I decided to investigate this behaviour.
My first thought was to look at earlier versions of ChatCraft, before we encountered this bug. Luckily, the ChatCraft repo has a workflow that builds and deploys a preview of all branches. Using this feature I was able to find and access an earlier version of ChatCraft I could study.
I noticed that in earlier visions of ChatCraft, created Shared Chats wouldn't redirect to a "api/share/" URL, but rather directly to a "/c/" URL:
Once I figured this out, I spent the last couple days studying how this happened. I knew that both the "api/share/" and "/c/" URLs were both valid, leading me to investigate the API methods written for these routes. The git grep command was useful in showing me this code:
A quick note on git grep
I can't stress enough how useful git grep was not just for this issue, but most of my open source work. Whenever I'm investigating an bug, I'm able to find clues like routes (such as the "/api/share" and "/c/" route patterns) or keywords to lookup using git grep. If not for this command I would have spent a lot more time investigating this issue.
However, beyond this point my investigation methods became inefficient. I began littering the codebase with console.log() statements wherever the "api/share" and "/c/" routes were being fetched. I also ended up switching between two branches - one where the bug was present and one where it wasn't - to observe the differences between them. After a day and a half of doing this I was able to figure out the issue, but I wish I knew a better way to do this.
The issue - Chats created with a new url
Eventually, my investigation revealed to me that around a month ago, a PR was merged that changed Shared Chats would be created. Shared Chats created after this PR would be given the "api/share"-style URL in the UI, while those created before the PR were given a "/c/"-style URL.
After some more investigation, I discovered this was due to a new method, createDataShareUrl():
Within this method is another method, createShareUrl(), that returns a "/c/"-style URL:
In the PR, calls to createShareUrl() (when creating a Shared Chat) were replaced with createDataShareUrl():
This turned out to be why some users observed this issue while others haven't: Those who observed the issue were trying to access Shared Chats made after this PR (with the "/api/share" URL), and those who didn't were accessing old Shared Chats made before this PR (with the "/c/" URL).
An imperfect solution
With this in mind, I was able to come up with a fix that uses createShareUrl() to give Shared Chats a "/c/"-style URL as before. However, I don't think it's the best fix. This is because it's only a partial fix. If this PR is merged, new Shared Chats created afterwards will be directly accessible via the UI again, but what about the Shared Chats that already have a "api/share"-style URL? Those still can't be accessed from the UI.
My ideal solution
My ideal solution to this issue would be to figure out why "api/share"-style URLs don't work when accessed through the UI and to fix that issue directly, so that both "api/share" and "/c/"-style URLs work from the UI.
I hope to take another look at this issue in the future, but I'd also like to work on adding new features to ChatCraft.
Next week in ChatCraft
In ChatCraft release 1.6, I hope to add a new feature related to adding Images, or action a better fix for the Shared Chats issue if it's not as difficult as I think.
Top comments (0)