I'm impacted by both bugs described here.
While I have been having the log page 500 error for a long while (at least since supabase CLI 1.93.0 and still to this day 1.106.1), the issue with the trigger page returning an error after refresh is something that I didn't see in previous versions.
Edit, the refresh bug on the trigger page seems to be solved in 1.110.1

I'm impacted by both bugs described here. While I have been having the log page 500 error for a long while (at least since supabase CLI 1.93.0 and still to this day 1.106.1), the issue with the trigger page returning an error after refresh is something that I didn't see in previous versions. Edit, the refresh bug on the trigger page seems to be solved in 1.110.1

Honestly I think the logs are more critical than the triggers not showing. We can still see the triggers through SQL queries (even though this is not an ideal solution/experience).
Logs on the other hand are critical to development. I'm getting errors and I have no way to debug them.

I'm also getting error 500 on logs page. Is this currently being worked on?

Hi guys - Are you having issues creating tables from using the Table Editor as well locally?

Hi guys - Are you having issues creating tables from using the Table Editor as well locally?

Not in my case. I can perform every other action except for logs.

Hi guys - Are you having issues creating tables from using the Table Editor as well locally?

I also have no issues creating tables and rows. Even the trigger erros seem to have been fixed in one of the latest versions.

I only have issues viewing the logs which are still showing a 500 error

We're also running into this issue. @kaumac, curious if you (or anyone else) have figured out a solution for this. Thanks!

Hi @kaumac, @joshling1919, Can I know to which port of analytic you are connecting?
During local development, we will need to make some adjustments to the port and API key of LOGFLARE
Here is my configuration; I hope it can be helpful.

Hi @kaumac, @joshling1919, Can I know to which port of analytic you are connecting? During local development, we will need to make some adjustments to the port and API key of LOGFLARE Here is my configuration; I hope it can be helpful.

Not sure I understand, do I need to make those changes on Docker?
The only thing I did was run supabase start

Also do I need to get an api key for this? Or "api-key" string works?

Hi @kaumac, @joshling1919, Can I know to which port of analytic you are connecting? During local development, we will need to make some adjustments to the port and API key of LOGFLARE Here is my configuration; I hope it can be helpful.

Not sure I understand, do I need to make those changes on Docker? The only thing I did was run supabase start

Hmm I don't even have "supabase_analytics_test", see screenshot

Honestly I feel like there's a lack of interest from supabase on the selfhosted stack. You can tell from the lack of features that you have on the hosted app.

This would be totally understandable (after all the selfhosted app doesn't bring in any money), except that the self hosted stack is a critical part of a mature/production app.

I develop locally and afterwards deploy to staging and production which are cloud (paid for) apps.

Supabase is such a great platform, you can tell there's a lot of hard work done on the cloud app, but I must say that the local development feels unpolished and somewhat painful to work with.

I have just written a Function and Trigger that was not working. Even the error message was blank in development/local.

I had to create a migration, deploy the migration to production (cloud/hosted app) just to see the error message and logs, then fix it on my local stack and create a migration with the fix.

The logs are very critical and I feel like they are not being given the attention they should 🙁

Local:

Production (cloud/hosted):

Hmm I don't even have "supabase_analytics_test", see screenshot

In the config.toml file, you can enable it as shown in this image:

Honestly I feel like there's a lack of interest from supabase on the selfhosted stack. You can tell from the lack of features that you have on the hosted app.

Feel free to create an issue in this repo. We will check and update it soon.

I have just written a Function and Trigger that was not working. Even the error message was blank in development/local.

Can you create another ticket for this issue?

Local: Production (cloud/hosted):

It has been resolved in the master code, and the release will be available soon.

Hmm I don't even have "supabase_analytics_test", see screenshot

In the config.toml file, you can enable it as shown in this image:

I was running into this same error and I needed to enable analytics in my config.toml file, but I had to add the entire analytics entry manually, likely because I was running an older project that was created before analytics were supported in the local studio. Doing that and restarting supabase, it pulled the logging containers and works correctly for me.

If it helps anybody... As mentioned above, to have logs locally, you need to edit config.toml and enable analytics:

[analytics]
enabled = false  <-- Set this to true
port = 54327
vector_port = 54328
\# Configure one of the supported backends: `postgres`, `bigquery`.
backend = "postgres" 

Important! After enabling, you need to restart supabase:
npm supa stop
npm supa start

I will close this as it is answered here and in the documentation.

Please comment (or open a PR) if you think it could be made clearer and we can re-evaluate!

I will close this as it is answered here and in the documentation.

in the documentation there it is called: LOGFLARE_SINGLE_TENANT_MODE and in the example docker-compose it is called LOGFLARE_SINGLE_TENANT
please adapt the documentation or docker-compose example depending which is the correct one.

@stefanstidlffg Thanks for calling that out, anyone is welcome to make a PR to make this clearer in the docs and align with the compose file. If not, I will do it later this week.