Upgrade to 0.7.5, or my own actions, have Librechat misbehaving

[jerkstorecaller]

What happened?

I've been using this wonderful app for 1 year. About 30 mins ago I updated from 0.7.2 to 0.7.5 to add o1-preview support, and now I'm having an issue: when a reply is received, the UI doesn't update. I must either reload the webpage or switch to a different chat and come back in order to see it.

UPDATE: see my reply below. There's no indication of any Librechat bugs and I don't think Danny should do anything. I'll leave this ticket open temporarily as doc in case it happens to other people, until I reply with my final conclusion.

Since there's no other issues about this, I guess I broke my installation somehow. I'm going to describe what I did and be thorough (including possibly irrelevant information) because it's likely possible an intermediate step broke my installation.

1. I edited .env to modify OPENAI_MODELS
2. I did the usual "git pull; docker compose down; docker pull; docker compose up -d" upgrade
3. Reload the page, the footer at the bottom shows 0.7.5
4. I notice the model list in the middle UI isn't my shortlist of 5 models. It seems to be a full list of every OpenAI model, without any o1 models
5. I recheck my .env for mistypes in OPENAI_MODELS, there are none. While I'm here, I decide to trim the .env file and start deleting every blank config entr, without touching the ones related to search and login or anything else with a value. POSSIBLY A BIG MISTAKE.
6. Restart Librechat, model list still a huge one missing my shortlist. I notice the list in the right side-bar is my correct shortlist, and if I select o1-preview there, then the middle one will be set to it.
7. I try to make a o1 generation, I see no reply
8. I realize reloading the page or switching to another chat and coming back lets me see the reply
9. I open the Firefox console and ask a question in a new chat. The UI won't update, but the console output is:

connection is opened
final Object { final: true, conversation: {…}, title: "New Chat", requestMessage: {…}, responseMessage: {…} }

10. I restore .env.example, set OPENAI_API_KEY and OPENAI_MODELS, and restart everything. Now the model list in the middle is fine, but the issue with the UI not updating after a reply persists.

So basically, the reply arrives, but the UI doesn't update to show it. There are no errors in any of the Docker containers. This is my only Linux server so I have nothing else to test with, unless I create a VM (which I can do tomorrow, I need to go to sleep already).

Warnings that might be the cause

(UPDATE from AFTER I wrote this stuff: on a working install, I still get the 3 warnings and Librechat still runs 100% fine, but I don't get the healthcheck error)

I use it from behind nginx, and have nginx reverse proxy the connection. I only use OpenAI.

When I open Librechat at gpt.me.com, the console shows:

Health check failed: 
Object { stack: "Qt@https://gpt.me.com/assets/vendor.DbZBOmc1.js:84:67639\noie[SNIP!!!], message: "Request failed with status code 401", name: "AxiosError", code: "ERR_BAD_REQUEST", config: {…}, request: XMLHttpRequest, response: {…}, status: 401 }
index.DOP20ZrM.js:3004:19876

When I open an existing chat from the history (gpt.me.com/c/someid), the console shows 3 warnings:

Invalid URI. Load of media resource  failed.
HTTP “Content-Type” of “text/html” is not supported. Load of media resource https://gpt.me.com/c/46c160d3-2e82-4313-b9b5-f8188de1badd failed.
Cannot play media. No decoders for requested formats: text/html

idk if this happened on my 0.7.2. It's possible it did and I never noticed because nothing was broken. Anyway, all 3 warnings have a clickable link to view-source:https://gpt.me.com/c/46c160d3-2e82-4313-b9b5-f8188de1badd46c160d3-2e82-4313-b9b5-f8188de1badd so I opened it, saw some links to /assets/.

About a year ago I created this issue: #889 about my nginx setup. Basically I use basic_auth protection for the whole app, but after talking to Danny in that ticket I had to make an exception and turn off basic_auth on calls to /api/* since you do your own auth by that point. So I figured, what if /c/ and /assets/ need non-auth access too in 0.7.5? So I gave them the same treatment as /api/, restarted nginx, unfortunately this hasn't changed anything, or even stopped the warnings, so idk.

Side issue: how can I migrate?
It's possible messing with the .env (even though I undid it and restarted later), permanently broke something, and it's not worth the time to fix issues you only run into when you take a bad path. If I have a way to migrate the existing accounts and chat history into a fresh install I'm happy to do it, but idk how.

Steps to Reproduce

I doubt this is reproducible.

1. Create a new chat
2. Ask a question

What browsers are you seeing the problem on?

Firefox

Relevant log output

No response

Screenshots

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[jerkstorecaller]

Update: I did some more tests in a local Linux VM, and accessing Librechat on http://localhost:3080.

TLDR: there's no indication of any Librechat bugs and I don't think Danny should do anything.

What I learned:

1. I first ran 5ef71a7 (0.7.2), then upgraded to 0.7.5, set my OPENAI_API_KEY and everything works fine. (NOTE: the 3 console warnings happen here too and they seem to have zero consequence. I don't get the health check error though)
2. I tried using my server's .env on this local installation, works fine too
3. The above was local tests using Librechat's webserver. So I set up nginx and proxied to Librechat the same way I do on the server (well, nginx was on Ubuntu in the VM, while on the server it's also a Docker container, but that shouldn't matter), and it still works fine.

So I'm mystified why my server installation is broken.

What I'm trying next is to do a fresh Librechat install on my server in another location, but copy the existing volumes holding my data. I'll report back. UPDATE: it's still broken. I mean, makes sense, there's something broken in one of the volumes, creating new containers wasn't gonna change that as it's no different from "docker compose down ; docker compose up".

My only hope now is migrating the data (users + history) to completely new volumes. I would appreciate some assistance here.