API service falling back to Mistral for file uploads for no (apparent) reason #7589
Replies: 1 comment
-
So it all miraculously started working - I don't think I changed anything though (after it wasn't working). My working theory is that there's a race condition somewhere - maybe one container booting faster than expected. But for now my problem has gone away. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
We have successfully configured one Librechat environment (staging), and are now setting up our main one (production) - however file uploads are refusing to work. File uploads are terminated almost immediately with a 500 error from
api
.The error we see in the log is as follows (which is kind of curious as it seems to be a fallback for when RAG API isn't working?)
I'm kind of out of ideas - connectivity between the
api
container andrag-api
containers appears to work - I can curl to the rag-api based on the environment variables (and have verified it's rag-api and not rag_api for us - due to k8s container naming in our charts).The API server is claiming -
RAG API is running and reachable at http://rag-api:8000.
- but I've seen comments online that maybe indicate that is not "completely" true.I feel like this is some subtle error that I'm missing - I've turned on debug logging and there's nothing I can see.
My staging and production environments should be the same (production has a firewall ingress on
api
, but that's the only thing different that I know of)Has anyone got any inspirational thoughts or is there some common case that I've missed that can go wrong?
My bug report I guess is... "it should be more obvious why the api is falling back to mistral rather than using rag-api"!
Beta Was this translation helpful? Give feedback.
All reactions