[BUG]: Linux AppImage - Error on update! (solution in comments)

[renegadephysicist]

How are you running AnythingLLM?

AnythingLLM desktop app

What happened?

System: Linux Ubuntu using AppImage
AythingLLM Version: 1.4.4
When attempting to change the "Workspace LLM Provider" in "Chat Settings" I get the error below.
Seems to be the same error for both anthropic and openai. It's possible to change the LLM at the instance level by changing "LLM Provider" just not at Workspace level

Error:
Invalid `prisma.workspaces.update()` invocation:

{
where: {
id: 3
},
data: {
chatProvider: "anthropic",
~~~~~~~~~~~~
chatModel: "claude-instant-1.2",
chatMode: "chat",
openAiHistory: 20,
openAiPrompt: "Given the following conversation, relevant context, and a follow up question, reply with an answer to the current question the user is asking. Return only your response to the question given the above information following the users instructions as needed.",
openAiTemp: 0.7,
? name?: String | StringFieldUpdateOperationsInput,
? slug?: String | StringFieldUpdateOperationsInput,
? vectorTag?: String | NullableStringFieldUpdateOperationsInput | Null,
? createdAt?: DateTime | DateTimeFieldUpdateOperationsInput,
? lastUpdatedAt?: DateTime | DateTimeFieldUpdateOperationsInput,
? similarityThreshold?: Float | NullableFloatFieldUpdateOperationsInput | Null,
? topN?: Int | NullableIntFieldUpdateOperationsInput | Null,
? workspace_users?: workspace_usersUpdateManyWithoutWorkspacesNestedInput,
? documents?: workspace_documentsUpdateManyWithoutWorkspaceNestedInput,
? workspace_suggested_messages?: workspace_suggested_messagesUpdateManyWithoutWorkspaceNestedInput,
? embed_configs?: embed_configsUpdateManyWithoutWorkspaceNestedInput,
? threads?: workspace_threadsUpdateManyWithoutWorkspaceNestedInput
}
}

Unknown argument `chatProvider`. Available options are listed in green.

I get an error when starting the AppImage:
EROFS: read-only file system, unlink '/tmp/.mount_Anythib4quPA/resources/backend/node_modules/.prisma/client/index.js'
Not sure if this is related or not.

Are there known steps to reproduce?

After clicking "Update Workspace" the following error should appear if a value different from "System Default" is selected for "Workspace LLM Provider"

[timothycarambat]

Fully close the application and re-open it so that the migrations can run and you can use that feature as it requires a migration. If the application was updated while running - the migrations will not run.

[renegadephysicist]

I've tried opening and closing the application several times yet the issue persists.
I only downloaded the AppImage today (version 1.4.4)

[timothycarambat]

Just modified the Linux version to help debug this issue. Can you see if this error reproduces with this app image?
https://s3.us-west-1.amazonaws.com/public.useanything.com/latest/AnythingLLMDesktop.AppImage

Let's see if this boots on your distro + allows you to update that workspace config. Definitely prisma related, but local to on the AppImage

[renegadephysicist]

I tried to run this appImage but I ran into the problem described here (#898). I tried to fix it but got the error below. Running Ubuntu 22.04.4, I didn't have this issue with the image I downloaded from the website.

[timothycarambat]

Okay, that was expected to be seen honestly. That was the previous issue. Just reverted to the prior image which was causing the original issue.

While the provider per workspace functionality is not available in 1.4.2, are you able to even set the model per workspace in this version (1.4.2)
https://s3.us-west-1.amazonaws.com/public.useanything.com/legacy/1.4.2/AnythingLLMDesktop.AppImage

[timothycarambat]

It looks like here, for some reason, the Prisma client is failing to generate after migration, this blocks the client from being able to use any updated schema and then fails to update workspaces who use the new fields from the updated schema

[renegadephysicist]

based on what you said

It looks like here, for some reason, the Prisma client is failing to generate after migration, this blocks the client from being able to use any updated schema and then fails to update workspaces who use the new fields from the updated schema

I tried to run the same process as described in #898 with the AppImage I downloaded earlier from the website

cd to where ur AnythingLLMDesktop.AppImage is
run ./AnythingLLMDesktop.AppImage --appimage-extract
cd squashfs-root/resources/backend/
node node_modules/prisma generate (will need node installed)
cd ../../
./AppRun

This worked, used node 20.12.2... I'm not familiar with javascript packaging, prisma etc. So I'm not sure how to fix this, maybe a CI step to create the AppImage?

[timothycarambat]

That likely could be the fix. Asking people to unzip the AppImage is a bit crazy so I wanted to hold off on recommending that, but it looks like patching the app post-install seems to be the most continuously reliable solution. :/

The main issue is that whatever CI we use to build the image we will have the same issue since Openssl binary native likely wont match what is used on the user OS and will instead come with whatever the CI was using.

Thinking we might just make the app a shell script at this point that can make the appimage on-machine to avoid all of these compatibility quirks. Docker just works for Linux on all distro but nobody wants to use that solution, which is why AppImage even exists

[renegadephysicist]

I asked ChatGPT lol and it came back with the following:

Prisma provides a feature to generate a static binary that includes all its dependencies. This can help ensure that the Prisma Client does not depend on the system's OpenSSL version. To generate a static binary for Prisma, you can configure your schema.prisma file with an appropriate binaryTargets option:

generator client {
  provider = "prisma-client-js"
  binaryTargets = ["native", "debian-openssl-1.1.x"]
}

This configuration tells Prisma to generate a client that is compatible with both the native platform it's generated on and specifically for debian-openssl-1.1.x. Adjust the binaryTargets as needed for your deployment target.

I'm not sure how you fixed this previously..
Here is the relevant prisma documentation, they mention this exact issue with the fix above:
https://www.prisma.io/docs/orm/prisma-schema/overview/generators

It looks like debian-openssl-1.1.x will target ubuntu up to 21.04 and debian-openssl-3.0.x for any version above that.
https://www.prisma.io/docs/orm/reference/prisma-schema-reference#linux-ubuntu-x86_64

Adding this to the prisma.schema generator client might do it:

generator client {
  provider = "prisma-client-js"
  binaryTargets = ["native", "debian-openssl-1.1.x",  "debian-openssl-3.0.x"]
}

[renegadephysicist]

I had a look at the package.json file that is used to create the electron app to see if I could figure out why the prisma schema is not being generated and I had to manually do it above.

I'm not familiar with prisma but it might be idea to put the generate command after the migrate command in the package.json file e.g.:

"prisma:setup": "yarn prisma:migrate && yarn prisma:generate && yarn prisma:seed",

[timothycarambat]

@renegadephysicist you may have just solved a big headache. Will see if we can wrap a new Linux version and test to see if this resolves everyone's issues. If this does, would be happy to mark you as a contributor

Related: prisma/prisma#8112

[naveenjujaray]

I concur that Prisma is the root cause of the problem, yet I find myself unable to rectify the situation.
you may find this helpful: prisma/prisma#5340

[timothycarambat]

For now. The solution to simply this for all distros is the run the AppImage in the following way:

./AnythingLLMDesktop.AppImage --appimage-extract && \
cd squashfs-root && \
./AppRun

This will ensure on run that the prisma binaries for your system are installed automatically. Since AppImages mount to /tmp/ and this in not writeable this is the current solution for Linux while we work on a workaround or comprehensive solution..

[wpq3142]

目前。对于所有发行版本来说，简单的解决方案是按以下方式运行AppImage：

./AnythingLLMDesktop.AppImage --appimage-extract && \
cd squashfs-root && \
./AppRun

这将保证在运行时prisma自动安装系统的二进制文件。由于AppImages挂载到/tmp/并且是不可写的，因此这是Linux的当前解决方案，同时我们正在研究解决方法或综合解决方案。

原来如此!!

[fengyunzaidushi]

For now. The solution to simply this for all distros is the run the AppImage in the following way:

./AnythingLLMDesktop.AppImage --appimage-extract && \
cd squashfs-root && \
./AppRun

This will ensure on run that the prisma binaries for your system are installed automatically. Since AppImages mount to /tmp/ and this in not writeable this is the current solution for Linux while we work on a workaround or comprehensive solution..

it works,thank you very much！

[la2yyu]

my system is windows, is there any sulution for this issue?

[13829386012]

我的系統是Windows，這個問題有什麼解決辦法嗎？

Me too,Encountered the same problem in windows system

[Yan2603]

我的系統是Windows，這個問題有什麼解決辦法嗎？

Me too,Encountered the same problem in windows system

我也遇到了，解决了吗