Closed WallK closed 7 months ago
Hi @WallK, thanks for opening the issue!
I think the problem reside in the backend.env
file, specifically here:
CACHE_HOST=cache
Please try to change that line to
CACHE_HOST=redis-cache
Since your redis
container is named redis-cache
Yep, I knew I missed to change something! Thank you!
It actually works now, custom plants are saved and shown!
While we are here: why the app need root db password? To create users and database if not present? Also, I'm still not sure how to add non-custom plants? (: I have added Trefle key in config and I can see Dactylis glomerata (I guess a demo plant added for me?), but how to add plant without clicking on Custom? I had expectations that I will have an ability to pick from a list or something. Was I mistaken?
Thank you again!
I think MYSQL_ROOT_PASSWORD
could be removed since not used in the codebase, I will better test this and cleanup the property if confirmed to not be used anymore, thanks for pointing out!
Regarding the Trefle integration, it seems to be functioning as expected if you're able to see Dactylis glomerata without having manually added it. The system should ideally display matching species when you search for a plant name, similar to the example below:
Could you please provide more details on the problem you're experiencing?
Alright, my problem was I was typing and erasing too fast haha It does appear if I wait a bit! Thank you!
I think there should be some indication (or onboarding, or just a bit more directly worded docs) on this, if it makes sense
Ah, another thing, about backend starting time
It takes unusually long time after restart to get up and running
I see 120 second timeout "Waiting for DB" (or something very similar) and then it takes 46 seconds or so to fully start
Is it a race condition with DB container? Backend has depends_on: - mariadb
in it, so it should be somewhat up by that point
I think DB is not fast enough to initialize before first call to it is made by plant-it backend, so it goes into that timeout script thingy
Or is it all normal behavior? Should I create another issue for this? Sorry for adding more comments about other stuff, it's just very tedious to fill you bug report template (and I'm really not sure it's a bug, this is just a "question")
Thanks again!
I think there should be some indication (or onboarding, or just a bit more directly worded docs) on this, if it makes sense
Currently I'm working on a big refactor on the frontend side, I'm developing a mobile app that will be available in the following weeks so expect some improvements on that side!
Ah, another thing, about backend starting time
I will check the backend startup issue, some changes will be implemented in the next release even on the backend side so hopefully this issue will be fixed. I will notify when the new release will be available and if the problem will persist I will surely take a look into that, thanks!
Sorry for adding more comments about other stuff, it's just very tedious to fill you bug report template (and I'm really not sure it's a bug, this is just a "question")
You're welcome to provide as much feedback and question as possible, I'm really happy to read them!
Avoid duplicated bug reports
Description
When I open the frontend in browser and log in -- I get "Unable to connect to Redis" notification
I'm not sure where "cache/:6379" and such comes from
This redis container uses default config and the same port
Does the application expects service name "cache" and nothing else?
Expected behaviour
No response
Steps to reproduce
No response
Local environment
It's a docker deployment Here's a relevant part of docker-compose.yaml:
Relevant part of plant-it-backend.env:
Additional info
Part of redis log:
Part of backend container log (this is the whole thing I can see in portainer):