Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-19 14:13:35 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #642] Chat via API does not show up in UI #365

New Issue
Closed
opened 2026-02-22 18:19:08 -05:00 by yindo · 6 comments
yindo commented 2026-02-22 18:19:08 -05:00
Owner
Copy Link
Copy Source

Originally created by @dlaliberte on GitHub (Jan 22, 2024).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/642

After I posted a 'chat' type message to a workspace via the API, I can see that message in the history of chats, obtained using the 'chats' API request, but it doesn't show up in the UI for the chats, even after I refreshed the entire UI page. Is that intentional?

The entry in the chat history doesn't appear to be any different than other messages. Here is that message, and the response I got.

    {
      "role": "user",
      "content": "This is a test of sending a message, posted via the AnythingLLM API.",
      "sentAt": 1705981132
    },
    {
      "role": "assistant",
      "content": "Thank you for testing the messaging functionality through the AnythingLLM API. I hope this test was successful and that you found the process easy to use. If you have any questions or encounter any issues during your testing, please feel free to reach out for assistance.",
      "sources": [...],
      "sentAt": 1705981132
    }

It must be that the UI is using a cache that is not being updated by the actual chat history. So this seems like a bug. It might be considered a feature that external chats and queries are not displayed in the UI, but since they are in the chat history, I would expect that they should affect the conversation, and should therefore be visible in the UI.

I tried 'stream-chat' as well, in case that made any difference. It didn't.

Originally created by @dlaliberte on GitHub (Jan 22, 2024). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/642 After I posted a 'chat' type message to a workspace via the API, I can see that message in the history of chats, obtained using the 'chats' API request, but it doesn't show up in the UI for the chats, even after I refreshed the entire UI page. Is that intentional? The entry in the chat history doesn't appear to be any different than other messages. Here is that message, and the response I got. ```json { "role": "user", "content": "This is a test of sending a message, posted via the AnythingLLM API.", "sentAt": 1705981132 }, { "role": "assistant", "content": "Thank you for testing the messaging functionality through the AnythingLLM API. I hope this test was successful and that you found the process easy to use. If you have any questions or encounter any issues during your testing, please feel free to reach out for assistance.", "sources": [...], "sentAt": 1705981132 } ``` It must be that the UI is using a cache that is not being updated by the actual chat history. So this seems like a bug. It might be considered a feature that external chats and queries are not displayed in the UI, but since they are in the chat history, I would expect that they should affect the conversation, and should therefore be visible in the UI. I tried 'stream-chat' as well, in case that made any difference. It didn't.
yindo added the question label 2026-02-22 18:19:08 -05:00
yindo closed this issue 2026-02-22 18:19:08 -05:00
yindo commented 2026-02-22 18:19:08 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Jan 23, 2024):

This behavior is only present when using the API for chats in a multi-user mode and it is intentional. This is because the API is not a "user" so its chats are not propagated to any users thread under a workspace. When in single-user mode the API chat response do append to the primary workspace thread and its like you sent a chat via the UI, since there are no "users" in single user.

@timothycarambat commented on GitHub (Jan 23, 2024): This behavior is only present when using the API for chats in a `multi-user` mode and it is intentional. This is because the API is not a "user" so its chats are not propagated to any users thread under a workspace. When in single-user mode the API chat response do append to the primary workspace thread and its like you sent a chat via the UI, since there are no "users" in single user.
yindo commented 2026-02-22 18:19:08 -05:00
Author
Owner
Copy Link
Copy Source

@dlaliberte commented on GitHub (Feb 9, 2024):

Since I need the API for chats to be visible in the workspace UI, I guess I need a way to return to single-user mode. I don't care if I have to reset the entire data store, all workspaces, etc. Probably will be easiest to just delete the whole local repo and clone it again.

But I'm not sure why the multi-user mode active means API chats can't be associated with individual users. A user coming in through an API chat could be authenticated via API calls just as well as when they log in. Or a special admin user might be the default user when using the API chats.

@dlaliberte commented on GitHub (Feb 9, 2024): Since I need the API for chats to be visible in the workspace UI, I guess I need a way to return to single-user mode. I don't care if I have to reset the entire data store, all workspaces, etc. Probably will be easiest to just delete the whole local repo and clone it again. But I'm not sure why the multi-user mode active means API chats can't be associated with individual users. A user coming in through an API chat could be authenticated via API calls just as well as when they log in. Or a special admin user might be the default user when using the API chats.
yindo commented 2026-02-22 18:19:08 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Feb 9, 2024):

if you need to reset everything and you are running from the repo just run yarn prisma:reset and it will reset everything

@timothycarambat commented on GitHub (Feb 9, 2024): if you need to reset everything and you are running from the repo just run `yarn prisma:reset` and it will reset everything
yindo commented 2026-02-22 18:19:08 -05:00
Author
Owner
Copy Link
Copy Source

@dlaliberte commented on GitHub (Feb 11, 2024):

I have run yarn prisma:reset, and the workspaces and documents were indeed removed. However, it appears I am not an admin user. I previously selected multi-user, but not after resetting the database. I don't see the "Security" menu in order to even try to switch to multi-user mode, but There is a Users menu, and the ability to try to add a user.

But when I try to create an admin user, I get the confusing Error: Unexpected token 'U', "Unauthorized" is not valid JSON. so I would guess I am not an admin user either.

I also rebuilt everything, starting with yarn setup, and the server, collector, frontend. And did another yarn prisma:reset as well. Same result.

So it appears that resetting the database is not quite enough to reset everything. What is missing? I see the AUTH_USER and AUTH_TOKEN are stored in the browser. Refreshing the page isn't doing enough. Visiting localhost:3000 in another browser, Edge in my case, does seem to work, however. So it is something stored in the browser that is not so easily reset.

Clearing the local storage with the Chrome dev tools, as shown in https://docs.devolutions.net/kb/general-knowledge-base/clear-browser-local-storage/clear-chrome-local-storage/, appears to have done the job.

So, would you consider it a bug that the browser local storage is out of sync with the server side? At least regarding this resetting of everything, it can be worked around. But are there other things stored in the browser's local storage that need to be synched with the server side? Will there be complications if multiple browser are used, either by one user or multiple users?

@dlaliberte commented on GitHub (Feb 11, 2024): I have run `yarn prisma:reset`, and the workspaces and documents were indeed removed. However, it appears I am not an admin user. I previously selected multi-user, but not after resetting the database. I don't see the "Security" menu in order to even try to switch to multi-user mode, but There is a Users menu, and the ability to try to add a user. But when I try to create an admin user, I get the confusing `Error: Unexpected token 'U', "Unauthorized" is not valid JSON`. so I would guess I am not an admin user either. I also rebuilt everything, starting with yarn setup, and the server, collector, frontend. And did another `yarn prisma:reset` as well. Same result. So it appears that resetting the database is not quite enough to reset everything. What is missing? I see the AUTH_USER and AUTH_TOKEN are stored in the browser. Refreshing the page isn't doing enough. Visiting localhost:3000 in another browser, Edge in my case, does seem to work, however. So it is something stored in the browser that is not so easily reset. Clearing the local storage with the Chrome dev tools, as shown in https://docs.devolutions.net/kb/general-knowledge-base/clear-browser-local-storage/clear-chrome-local-storage/, appears to have done the job. So, would you consider it a bug that the browser local storage is out of sync with the server side? At least regarding this resetting of everything, it can be worked around. But are there other things stored in the browser's local storage that need to be synched with the server side? Will there be complications if multiple browser are used, either by one user or multiple users?
yindo commented 2026-02-22 18:19:08 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Feb 12, 2024):

Did you at any point change your role from something to admin? That would be the reason it was giving unauthorized, logging out and back in would have solved this. Are you running the application in development mode?

@timothycarambat commented on GitHub (Feb 12, 2024): Did you at any point change your role from something to admin? That would be the reason it was giving unauthorized, logging out and back in would have solved this. Are you running the application in development mode?
yindo commented 2026-02-22 18:19:08 -05:00
Author
Owner
Copy Link
Copy Source

@dlaliberte commented on GitHub (Feb 13, 2024):

Did you at any point change your role from something to admin? That would be the reason it was giving unauthorized, logging out and back in would have solved this.

I never created a second user, so I was always admin.

Are you running the application in development mode?

I am always running from Ubuntu shells my local clone of the repo, using the yarn setup etc process.

@dlaliberte commented on GitHub (Feb 13, 2024): > Did you at any point change your role from something to admin? That would be the reason it was giving unauthorized, logging out and back in would have solved this. I never created a second user, so I was always admin. > Are you running the application in development mode? I am always running from Ubuntu shells my local clone of the repo, using the `yarn setup` etc process.
yindo changed title from Chat via API does not show up in UI to [GH-ISSUE #642] Chat via API does not show up in UI 2026-06-05 14:34:55 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Desktop
Docker
Integration Request
Integration Request
OS: Linux
OS: Mobile
OS: Windows
UI/UX
blocked
bug
bug
core-team-only
documentation
duplicate
embed-widget
enhancement
feature request
github_actions
good first issue
investigating
needs info / can't replicate
possible bug
pull-request
Mirrored from GitHub Pull Request
 question
stage: specifications
wontfix
No Label question
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#365
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?