The thing is that in the next step I get this error: “Error checking table status: [Errno 111] Connection refused” both before and after running the SQL query.
Now, for the life of me I cannot find how to track this error or where to look. Archon does not display any error in the logs, and in the Local AI stack I’ve checked every container in the stack but cannot find anything.
Just so you know, the Local AI stack works flawlessly.
Also, on a side note, @ColeMedin I was expecting an error in when crawling the Pydantic documentation. The fetching and digesting of the info goes fine, but if it cannot write to the DB, it should either stop or print the error on the screen. But neither happens and one may think the info is on the DB when it is not.
I set it up yesterday with a similar setup, and it populated the database, but when i restarted my local ai, suddenly i started getting the same error as you.
Many thanks @patkelman for the suggestion. I did find the place you mention and disabled RLS. It was the only setting there that was enabled, by the way.
Yes, the /project was there as a test. I’m no longer using that, only http://localhost:8000. It makes no difference.
Also, using both keys, Anon or Service, curiouslyI get the same error. If I use a made up one (ex: 1234) then I’m asked to set the environment properly.
I’ve even tried setting the .env. It does not populate the data in the Archon Environment webpage, but going to the Database part shows the same error.
This screenshot is just to show that .env file, environment of the Archon container and the actual configuration of Supabase do match on for the Service Key.
So I’m starting to think it is the way Archon processes/presents the Key to Supabase that changes something. Or that Archon/Supabase do not understand each other or something like this.
So to close the loop here I went to the python install over the docker , and also removed RLS. Once I did this all my issues went away and suddenly it all worked as intended. Thanks
The worst part of learning is not knowing what one may know but not knowing what one does not know and I definitely do not know when is localhost and when is host.docker.internal.